Re: Optimal Tape Blocksize
From: "Gibney, Dave" > There is a setting in your Natural Nucleus parms for blksize, it should > be set to use SDB. I'm not our NAT admin, I don't remember the specific > parm or value. Dave, you are right, I checked this parm in the Natural nucleus with our DB admin. It is 6428. That's why our programmer got such a horrendous blksize on tape. Thanks again. 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
--- On Fri, 3/27/09, Patrick O'Keefe wrote: > From: Patrick O'Keefe > Subject: Re: Optimal Tape Blocksize > To: IBM-MAIN@bama.ua.edu > Date: Friday, March 27, 2009, 5:12 PM > On Fri, 27 Mar 2009 14:54:51 -0400, > Bill Fairchild > > wrote: > > >... > >In 1982 I attended a SHARE session in New Orleans in > which the IBM > presenter said that he had surveyed a huge number of data > sets in an > internal IBM development data center, and had found that > the single > most commonly used block size was 80 bytes. > Presumably many of > these people had been developing mainframe code since the > early > 1960s when S/360 began being built. > >... > > It would be nice if such things were in the distant > past. As recently > as 5 years ago I say some Program Directories specifying > block sizes > of 3120 and 6144. > > Worse yet, just a few weeks ago we were told to > allocate a trace > dataset (for an IBM product) with RECFM VB, LRECL 1024, and > > BLKSIZE 6144. (Obviously the product's own flavor of > trace; not > GTF or CTRACE.) 6144! This came from the > product's lvl2 support > team. Did they know that this was needed for a very > poorly written > trace furntion? Or did they just pick a > cherished (now thoroughly > meaningless) blksize from the distant > past? Either way, it did not > inspire confidence. > > Pat O'Keefe Pat: That *MAY* have been our IBM SE at the time Jim Garner. He was published in an orange manual. I do not think I have it anymore and I forgot to get him to sign it. The other big thing (IIRC) was not only blocksize was important but using 5 buffers (instead of 2 which was the default at the time (that were several charts in the manual showing optimal trade offs). Since its been so long ago my memory could be off at the time but shortly after he was published SAMe came along. We found a few (chuckle) issues in it and we were almost always running GTF to try and find the bugs. I think (IIRC) we got at least 10 APARS out of SAMe. We had many many tape drives and many disk drives as well. The amount of I/O is truly scary at any point in time. SAMe (IIRC) cost $85 a month at the time and it was a savior (to us) we cut our elapsed time down quite a bit but at the same time it cost storage so it was about equal. The support we got out of IBM was world class, I think we should have gotten it for free myself:) 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
Re: Optimal Tape Blocksize
At 15:21 -0500 on 03/27/2009, Tom Marchant wrote about Re: Optimal Tape Blocksize: If there is a block size coded in the DCB macro (or FD), that is the block size that will be used. JCL will not override it. Neither will the label or the DSCB. True. OTOH, the Tape Label or DSCB Block Size had BETTER be smaller than the DCB one for input files or you are going to get into trouble reading the data since your buffers will be too small and you will have I/O errors trying to read blocks larger than your input block size. -- 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: Optimal Tape Blocksize
At 15:36 -0500 on 03/27/2009, Paul Gilmartin wrote about Re: Optimal Tape Blocksize: "How to Lie with Statitics" topic="mode". Huff's 50 year book still lives and is still in print. -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 14:54:51 -0400, Bill Fairchild wrote: >... >In 1982 I attended a SHARE session in New Orleans in which the IBM presenter said that he had surveyed a huge number of data sets in an internal IBM development data center, and had found that the single most commonly used block size was 80 bytes. Presumably many of these people had been developing mainframe code since the early 1960s when S/360 began being built. >... It would be nice if such things were in the distant past. As recently as 5 years ago I say some Program Directories specifying block sizes of 3120 and 6144. Worse yet, just a few weeks ago we were told to allocate a trace dataset (for an IBM product) with RECFM VB, LRECL 1024, and BLKSIZE 6144. (Obviously the product's own flavor of trace; not GTF or CTRACE.) 6144! This came from the product's lvl2 support team. Did they know that this was needed for a very poorly written trace furntion? Or did they just pick a cherished (now thoroughly meaningless) blksize from the distant past? Either way, it did not inspire confidence. Pat O'Keefe -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 15:21:20 -0500, Tom Marchant wrote: >... >If there is a block size coded in the DCB macro (or FD), that is the >block size that will be used. JCL will not override it. Neither will >the label or the DSCB. >... It's worth remembering something said much earlier in this thread, though. The resulting BLKSIZE and the size of the written blocks may not be the same - may have nothing to do with each other. It really depends on the drive and controller. Pat O'Keefe -- 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: Doubleword alignment (was: Optimal tape blocksize)
On Thu, 26 Mar 2009 19:34:01 +, john gilmore wrote: > >The chief problem with not having "the end of one's [i-th] buffer" >doubleword-aligned is that the beginning of the (i+1)-th and all subsequent >buffers will not have their beginnings doubleword aligned. > Well, FSVO "all". >A logical record will not then in general be doubleword aligned in its buffer, >with the consequence that it will be unusable for locate-mode i/o operations >if any of its fields has an internal halfword, fullword, or doubleword >alignment requirement. > So, because some programmers might benefit by having logical records doubleword aligned, should all programmers be forbidden to use a block size not a multiple of 8? Better to allow a few slack bytes between buffers. But you motivated me to write a simple (no threat to RSA) factoring program, which tells me: 496 $ factor 32760 Factors of 32760 are 2 2 2 3 3 5 7 13 32767 Factors of 32767 are 7 31 151 I suppose divisors of 32767 are only marginally useful. -- gil -- 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: Optimal Tape Blocksize
>Will COBOL ever outgrow the default of CONTAINS 1? Perhaps by installation
>PARM option?
Perhaps by education of App programmers?
Of course, the nice thing about standards is there are so manyu to choose from.
(8-{]}
-
Too busy driving to stop for gas!
--
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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 14:54:51 -0400, Bill Fairchild wrote: > >In 1982 I attended a SHARE session in New Orleans in which the IBM presenter >said that he had surveyed a huge number of data sets in an internal IBM >development data center, and had found that the single most commonly used >block size was 80 bytes. Presumably many of these people had been developing >mainframe code since the early 1960s when S/360 began being built. > "How to Lie with Statitics" topic="mode". That might mean that 1% of data sets have BLKSIZE=80 but no particular other value rises to that frequency. 1% is probably still too much; that could waste a disproportionately large fraction of DASD space. Will COBOL ever outgrow the default of CONTAINS 1? Perhaps by installation PARM option? -- gil -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 18:42:46 +, Ted MacNEIL wrote: > >I've seen very many apps people who didn't know about block size efficiencies. There are people in every area who know less than they should. When I see people criticizing any group with such a broad statement, I wonder where the problem really lies. >I knew one who had just copied the same FD's for many years, just >changing the LRECL, as needed, and leaving BLOCK CONTAINS 1 in. He wouldn't have survived where I worked as an applications programmer starting in 1970. At that time, *all* of the programmers knew that they had to specify block contains 0 in the FD. The problem with specifying a blocksize in the DCB predates SDB by many years. When the program specifies a blocksize in the DCB, it cannot use the blocksize of the input data set. -- Tom Marchant -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 14:03:08 -0500, Dave Kopischke wrote: > >When we switched, we found some programs specify block sizes and blocking >factors. If this happens, SDB doesn't get invoked. In this case, you HAVE to >specify a reasonable blocksize in your JCL. > But that won't work if BLKSIZE is coded in the DCB. It's dismaying that some programmers are apparently so sophisticated as to code a DCB exit, then choose a bad value. (But I did it in 3350 era; BLKSIZE=6000.) >I haven't seen this happen with any utilities, but I do see utilities >propogating >a bad blocksize from the input. > IEBGENER is vacillating. It's now a PARM option. For a while it made the fault SDB, but it has reverted to propagating; likely because of customer input. -- gil -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 14:03:08 -0500, Dave Kopischke wrote: > >When we switched, we found some programs specify block sizes and blocking >factors. If this happens, SDB doesn't get invoked. In this case, you HAVE to >specify a reasonable blocksize in your JCL. If there is a block size coded in the DCB macro (or FD), that is the block size that will be used. JCL will not override it. Neither will the label or the DSCB. -- Tom Marchant -- 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: Optimal Tape Blocksize
Untrue cases a rare, should be getting more rare, and should be fixed! Some utilities (Syncsort) allow you to specify where to copy blksize from input or use SDB Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Dave Kopischke > Sent: Friday, March 27, 2009 12:03 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Optimal Tape Blocksize > > On Fri, 27 Mar 2009 02:54:10 -0700, Walter Marguccio wrote: > > > > >I agree 100%. I told our programmers long ago to stick to > >BLKSIZE=0 *and* DSORG=PS for datasets on DASD. This always work > >(BLKSIZE close to half track). > > This is not always true > > > > >I can't understand why such poor BLKSIZE are chosen. I would really > appreciate > >if anyone could shed some light on this. > > > > When we switched, we found some programs specify block sizes and > blocking > factors. If this happens, SDB doesn't get invoked. In this case, you > HAVE to > specify a reasonable blocksize in your JCL. > > I haven't seen this happen with any utilities, but I do see utilities > propogating > a bad blocksize from the input. > > -- > 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: Optimal Tape Blocksize
Thoroughly understandable. Hmm, they sold DASD back then didn't they ? ;-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Friday, March 27, 2009 1:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Optimal Tape Blocksize From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, March 27, 2009 2:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Optimal Tape Blocksize >I've seen very many apps people who didn't know about block size efficiencies. In 1982 I attended a SHARE session in New Orleans in which the IBM presenter said that he had surveyed a huge number of data sets in an internal IBM development data center, and had found that the single most commonly used block size was 80 bytes. Presumably many of these people had been developing mainframe code since the early 1960s when S/360 began being built. Bill Fairchild Rocket Software -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.30/2026 - Release Date: 03/27/09 07:13:00 -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 02:54:10 -0700, Walter Marguccio wrote: > >I agree 100%. I told our programmers long ago to stick to >BLKSIZE=0 *and* DSORG=PS for datasets on DASD. This always work >(BLKSIZE close to half track). This is not always true > >I can't understand why such poor BLKSIZE are chosen. I would really appreciate >if anyone could shed some light on this. > When we switched, we found some programs specify block sizes and blocking factors. If this happens, SDB doesn't get invoked. In this case, you HAVE to specify a reasonable blocksize in your JCL. I haven't seen this happen with any utilities, but I do see utilities propogating a bad blocksize from the input. -- 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: Optimal Tape Blocksize
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, March 27, 2009 2:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Optimal Tape Blocksize >I've seen very many apps people who didn't know about block size efficiencies. In 1982 I attended a SHARE session in New Orleans in which the IBM presenter said that he had surveyed a huge number of data sets in an internal IBM development data center, and had found that the single most commonly used block size was 80 bytes. Presumably many of these people had been developing mainframe code since the early 1960s when S/360 began being built. Bill Fairchild Rocket Software -- 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: Optimal Tape Blocksize
>Programmers who set blocksize in the application code should be "educated", >perhaps using a "cluestick" :) I've seen very many apps people who didn't know about block size efficiencies. Many had over 15 years experience. I knew one who had just copied the same FD's for many years, just changing the LRECL, as needed, and leaving BLOCK CONTAINS 1 in. He didn't understand the need for a 'better' BLKSIZE. I ended up giving a presentation to his whole department, a long time ago (pre-SDB/LARGE Blocks), on what efficiencies could be gained. Over the span of a year, we saw improvements to the batch window, and tape/disk utilisation. They didn't make a project out of it; they just modified the FD's, whenever they had to open up the programme. - Too busy driving to stop for gas! -- 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: Optimal Tape Blocksize
On Fri, 27 Mar 2009 08:20:43 -0400, John Kington wrote: > >It is very possible that Natural is using the dcb exit that I mentioned in >my other email. Hopefully, the means and values are documented somewhere >and even better, changeable. > IBM has been known to repair by APAR components that prevented (perhaps by DCB exit) operation of SDB. IBM has been known to take an additional APAR when SDB then chose a blocksize incompatible with, e.g., LRECL and RECFM. -- gil -- 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: Optimal Tape Blocksize
There is a setting in your Natural Nucleus parms for blksize, it should be set to use SDB. I'm not our NAT admin, I don't remember the specific parm or value. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Walter Marguccio > Sent: Friday, March 27, 2009 5:05 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Optimal Tape Blocksize > > From: "Vernooy, C.P. - SPLXM" > > > The order is: F1DSCB, which can be overruled by JCL, which can be > > overruled by the application at OPEN time. > > Kees, Ted, Terry, > > thanks very much for your reply. I first looked at 'z/OS 1.9 DSMS Using > Data Sets', > but could not find such a direct statement. I will pass this info to our > programmers > and see how Natural can make a better use of blksize when data is written > to tape. > > 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: 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: Optimal Tape Blocksize
Actually, DATACLAS comes first, which can then be overridden as stated. A "good" SMS configuration always sets a default DSORG of PS. Programmers who set blocksize in the application code should be "educated", perhaps using a "cluestick" :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Friday, March 27, 2009 3:58 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Optimal Tape Blocksize > > > > "Ted MacNEIL" wrote in message > news:<1799752802-1238150510-cardhu_decombobulator_blackberry.rim.net-796 > 5151...@bxe1305.bisx.prod.on.blackberry>... > > >are you saying that the application program which actually writes the > tape has the last word to decide how to block the dataset on tape ? > > > > This is explained in the JCL manual, in the section regarding BLKSIZE > (at least it used to be). > > But, the short answer is "YES". > > > > The order is: F1DSCB, which can be overruled by JCL, which can be > overruled by the application at OPEN time. > > Kees. > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@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: Optimal Tape Blocksize
Walter, > Kees, Ted, Terry, > > thanks very much for your reply. I first looked at 'z/OS 1.9 DSMS > Using Data Sets', > but could not find such a direct statement. I will pass this info to > our programmers > and see how Natural can make a better use of blksize when data is > written to tape. > It is very possible that Natural is using the dcb exit that I mentioned in my other email. Hopefully, the means and values are documented somewhere and even better, changeable. Regards, John -- 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: Optimal Tape Blocksize
Walter, > > I thought BLKSIZE=0 would also let the system choose the optimal bloksize > for datasets on tape. I'm starting to review datasets on tape the way Lizette > is doing, and I can see that in some cases the chosen bloksize is really poor. > (i.e. RECFM=FB,LRECL=22,BLKSIZE=0 in jcl, but I see BLKSIZE=4620 > under DFSMSrmm) > > In my DEVSUPxx I have only coded COMPACT=YES. > > I can't understand why such poor BLKSIZE are chosen. I would really > appreciate > if anyone could shed some light on this. > As Kees noted, the program could have a blocksize in imbedded which overrides anything from the label and jcl. Another way for a program to override the blocksize is to include a dcb exit to set the blocksize. Unlikely but possible if you do not find a hardcoded blocksize in the dcb in the program. Regards, John -- 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: Optimal Tape Blocksize
On Thu, 26 Mar 2009 20:32:35 +, Ted MacNEIL wrote: > >When SDB came out, you still had to specify something. >In other words, BLKSIZE had to be coded. Not true. If you code a DCB macro without a BLKSIZE, the blocksize field in the DCB is left as zero. That is not the same as specifying zero, but it has the same effect. Likewise, if no BLKSIZE is specified in the JCL, the value in the DCB remains zero. This allows SDB to be used for a new data set, or the block size in the VTOC or tape label to be used for an existing data set. -- Tom Marchant -- 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: Optimal Tape Blocksize
From: "Vernooy, C.P. - SPLXM" > The order is: F1DSCB, which can be overruled by JCL, which can be > overruled by the application at OPEN time. Kees, Ted, Terry, thanks very much for your reply. I first looked at 'z/OS 1.9 DSMS Using Data Sets', but could not find such a direct statement. I will pass this info to our programmers and see how Natural can make a better use of blksize when data is written to tape. 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
Field, Alan C. pisze: Is it old school thinking. Isn't as close to 32670 as you can the optimal? If you use BLKSIZE=0 in your JCL you should be achieving that. BLKSIZE=0 is *not enough* for tapes (in general). See BLKSZLIM in DD and DEVSUP parameter. Last, but not least is the application, i.e. IEBGENER PARM='SDB=INPUT|SMALL|LARGE|NO' For 3490E tapes optimal blocksize is maximum one, which is 64kB. For 3590B,E,H and 3592 it is 256kB. I was told that physical block size on the tape is not necessarily equal the logical one - that means transmitted from MVS image. In other words tape drive controller can reblock the data as needed. Remember about compression - 256kB block from MVS is usually smaller on the tape! However it is still worth to use optimal block sizes. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Optimal Tape Blocksize
Hi Walter, With regard to "are you saying that the application program which actually writes the tape has the last word to decide how to block the dataset on tape?" Historically DCB information has been acquired via the Open/Merge process which applies to data sets irrespective of them being tape or disk based. The DCB information sources are in order: 1) The program 2) The JCL 3) The File Label If the DCB is incomplete after all three are processed then S013 occurs. Thus if it is a COBOL program and the programmer specifies something other than BLOCK CONTAINS 0, then the program value will be taken and the other two sources will be ignored. A lot of installations have a standard of coding BLOCK CONTAINS 0 to provide for the flexibility of being able to adjust BLKSIZE via the JCL for output data sets. It is logical for consistency that BLKSIZE=0, (invoking SDB) would only be relevant if the program has allowed the option which has Ted mentioned is discussed in the JCL manual. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Optimal Tape Blocksize
"Ted MacNEIL" wrote in message news:<1799752802-1238150510-cardhu_decombobulator_blackberry.rim.net-796 5151...@bxe1305.bisx.prod.on.blackberry>... > >are you saying that the application program which actually writes the tape has the last word to decide how to block the dataset on tape ? > > This is explained in the JCL manual, in the section regarding BLKSIZE (at least it used to be). > But, the short answer is "YES". > The order is: F1DSCB, which can be overruled by JCL, which can be overruled by the application at OPEN time. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
>are you saying that the application program which actually writes the tape has >the last word to decide how to block the dataset on tape ? This is explained in the JCL manual, in the section regarding BLKSIZE (at least it used to be). But, the short answer is "YES". I've known experienced application programmers who didn't "know better"; they just didn't "know". - Too busy driving to stop for gas! -- 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: Optimal Tape Blocksize
From: "Vernooy, C.P. - SPLXM" > Beware that BLKSIZE=0 only sets the default. The application might have > overriden this to 4620 in this case. Applications sometimes think they > 'know' what is best. Kees, are you saying that the application program which actually writes the tape has the last word to decide how to block the dataset on tape ? 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
"Walter Marguccio" wrote in message news:<601975.75598...@web50805.mail.re2.yahoo.com>... > >From: "Gibney, Dave" > > > Still, why worry about details the system will handle for you. > > I agree 100%. I told our programmers long ago to stick to > BLKSIZE=0 *and* DSORG=PS for datasets on DASD. This always work > (BLKSIZE close to half track). > > > Behalf Of Ted MacNEIL > > On tape, it's as close to the maximum as possible. > > I thought BLKSIZE=0 would also let the system choose the optimal bloksize > for datasets on tape. I'm starting to review datasets on tape the way Lizette > is doing, and I can see that in some cases the chosen bloksize is really poor. > (i.e. RECFM=FB,LRECL=22,BLKSIZE=0 in jcl, but I see BLKSIZE=4620 under DFSMSrmm) > > In my DEVSUPxx I have only coded COMPACT=YES. > > I can't understand why such poor BLKSIZE are chosen. I would really appreciate > if anyone could shed some light on this. > > TIA > > Walter Marguccio Beware that BLKSIZE=0 only sets the default. The application might have overriden this to 4620 in this case. Applications sometimes think they 'know' what is best. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
>From: "Gibney, Dave" > Still, why worry about details the system will handle for you. I agree 100%. I told our programmers long ago to stick to BLKSIZE=0 *and* DSORG=PS for datasets on DASD. This always work (BLKSIZE close to half track). > Behalf Of Ted MacNEIL > On tape, it's as close to the maximum as possible. I thought BLKSIZE=0 would also let the system choose the optimal bloksize for datasets on tape. I'm starting to review datasets on tape the way Lizette is doing, and I can see that in some cases the chosen bloksize is really poor. (i.e. RECFM=FB,LRECL=22,BLKSIZE=0 in jcl, but I see BLKSIZE=4620 under DFSMSrmm) In my DEVSUPxx I have only coded COMPACT=YES. I can't understand why such poor BLKSIZE are chosen. I would really appreciate if anyone could shed some light on this. TIA 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
Edward Jaffe wrote: We code TAPEBLKSZLIM=2G in DEVSUPxx. I'm not sure if the system uses 128K or 256K blocks for our 3590s when LBI is used... Alex tells me [off-list] that the DCE contains two fields: recommended and maximum block size at offsets x'5C' and x'60' into the DCE. You can display this control block using the "DS QT,,UCB,DCE" command. Here's what's shown for one of our 3590-H11s. Both recommended and max block size values are x'4' = 256KB: IEE459I 13.17.46 DEVSERV QTAPE 604 UNIT DTYPE DSTATUS CUTYPE DEVTYPE CU-SERIAL DEV-SERIAL ACL LIBID 1500 3590 ON-RDY 3590A60 3590H11* 0113-45451 0113-45451 I-A UCB AT V0220DB20 0008FF801500 00E4C3C2 780480830020DAF9 E00C 8346000E UCB PREFIX AT V022379F0 000D8040 000100A0 289801B9C00080C0 132F 01080001 UCB COMMON EXTENSION AT V0220DAF8 2300FB00200E0028 022379F0 00FD811C 0220DA801800 DCE AT V0220DA80 E4C3C2E300788000 00A4 0B00 B18B FF66 0004 0004000E 8000 2300FB00200E0028 022379F0 00FD811C 0220DA801800 034EFE80 0008FF801500 00E4C3C2 780480830020DAF9 E00C 8346000E E4C3C2E3 1 DEVICE(S) MET THE SELECTION CRITERIA 1 DEVICE(S) WITH DEVICE EMULATION ACTIVE HTH ... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
>Still, why worry about details the system will handle for you. I agree on that one. >Production JCL Standards should flag any use of BLKSIZE=. >It's not required and often wrong. When SDB came out, you still had to specify something. In other words, BLKSIZE had to be coded. If it doesn't any more, great! - Too busy driving to stop for gas! -- 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: Optimal Tape Blocksize
Roach, Dennis , N-GHG wrote: Does it really make a difference? IIRC, starting with 3490, the control unit compressed and buffered the data and then wrote to the physical tape in a fixed, very large block size. This being the case, block size only impacts the channel utilization and with fiber channels, I have not seen this to be an issue. It generally doesn't make a difference in tape utilization, but larger block sizes still reduce the number of passes thru the I/O supervisor (EXCP/STARTIO and I/O interupts). -- Richard -- 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
Doubleword alignment (was: Optimal tape blocksize)
Paul Gilmartin wrote: | What particular penalty is incurred by not having the | end of one's buffer doubleword aligned, supposing 32767 | fits one's data well? The chief problem with not having "the end of one's [i-th] buffer" doubleword-aligned is that the beginning of the (i+1)-th and all subsequent buffers will not have their beginnings doubleword aligned. A logical record will not then in general be doubleword aligned in its buffer, with the consequence that it will be unusable for locate-mode i/o operations if any of its fields has an internal halfword, fullword, or doubleword alignment requirement. Alignment within a record in the responsibility of the programmer, not the system; but the system makes the assumption of this responsibility possible by aligning STORAGE-obtained blocks of storage, buffers, etc., on a doubleword boundary. Move-mode i/o is, as I am sure you know, tedious. I am alsooo sure that I have sometimes suspected you unfairly of seeking only to épater l’IBM when you pose such questions, but this time? John Gilmore Ashland, MA 01721-1817 USA _ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009 -- 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: Optimal Tape Blocksize
May not be magic, but it is convenient. It'd be real close to magic if it recognized loadlibs and used 32760 :) Still, why worry about details the system will handle for you. Production JCL Standards should flag any use of BLKSIZE=. It's not required and often wrong. Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Ted MacNEIL > Sent: Thursday, March 26, 2009 11:30 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Optimal Tape Blocksize > > >Bigger the better, but I just use SDB :) > > SDB is not magic. > On disk, it's as close to half track, as possible, without going over. > On tape, it's as close to the maximum as possible. > > - > Too busy driving to stop for gas! > > -- > 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: Optimal Tape Blocksize
>Bigger the better, but I just use SDB :) SDB is not magic. On disk, it's as close to half track, as possible, without going over. On tape, it's as close to the maximum as possible. - Too busy driving to stop for gas! -- 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: Optimal Tape Blocksize
Does it really make a difference? IIRC, starting with 3490, the control unit compressed and buffered the data and then wrote to the physical tape in a fixed, very large block size. This being the case, block size only impacts the channel utilization and with fiber channels, I have not seen this to be an issue. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Lizette Koehler > Sent: Thursday, March 26, 2009 12:22 PM > > I am going to be doing an analysis on our tapes to see if they are > optimally blocked. We are using VTS that looks like 3490E tapes. > > Is there a good rule of thumb for all datasets on tape - that to be > blocked optimally use X? > > The lrecls on these tape range from 80 to 10399 > > Lizette -- 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: optimal tape blocksize
On Thu, 26 Mar 2009 17:50:43 +, john gilmore wrote: > >[2^15 - 1 =] 32767/8 is 4095, and 4095 x 8 is 32760, > >which is the largest integer not greater than 32767 that is a multiple of >eight (for doubleword alignment). > What particular penalty is incurred by not having the end of one's buffer doubleword aligned, supposing 32767 fits one's data well? I suppose that if GETMAIN allocates in doubleword units (rounding up, I hope), one byte will always be unused. That does not strike me as an exorbitant price. -- gil -- 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: optimal tape blocksize
Thanks John. I tell people I can spell, I just can't type. Looks like I can't type numbers either :) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of john gilmore Sent: Thursday, March 26, 2009 12:51 To: IBM-MAIN@bama.ua.edu Subject: Re: optimal tape blocksize Ed Jaffe got in first. Still, Allen Fields's typo needs correction for the record. For old-style blocking the maximal BLKSIZE= value was 32760---not 32670. The rationale for it was that the integer quotient of [2^15 - 1 =] 32767/8 is 4095, and 4095 x 8 is 32760, which is the largest integer not greater than 32767 that is a multiple of eight (for doubleword alignment). John Gilmore Ashland, MA 01721-1817 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: optimal tape blocksize
Ed Jaffe got in first. Still, Allen Fields's typo needs correction for the record. For old-style blocking the maximal BLKSIZE= value was 32760---not 32670. The rationale for it was that the integer quotient of [2^15 - 1 =] 32767/8 is 4095, and 4095 x 8 is 32760, which is the largest integer not greater than 32767 that is a multiple of eight (for doubleword alignment). John Gilmore Ashland, MA 01721-1817 USA _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009 -- 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: Optimal Tape Blocksize
John McKown wrote: For tape (especially modern tape), I've always here that the optimal BLKSIZE is as big as you can make it. For "normal" VB files that would be 32767. For FB files, the largest multiple of the LRECL <= 32767. IIRC, there are some products which can exceed this. But the QSAM/BSAM access method is stuck at 32767. At least until somebody tells me that I am totally out of date, again. We code TAPEBLKSZLIM=2G in DEVSUPxx. I'm not sure if the system uses 128K or 256K blocks for our 3590s when LBI is used. But, tape block sizes can be much larger than what you've stated above. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Optimal Tape Blocksize
Is it old school thinking. Isn't as close to 32670 as you can the optimal? If you use BLKSIZE=0 in your JCL you should be achieving that. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Thursday, March 26, 2009 12:22 To: IBM-MAIN@bama.ua.edu Subject: Optimal Tape Blocksize I am going to be doing an analysis on our tapes to see if they are optimally blocked. We are using VTS that looks like 3490E tapes. Is there a good rule of thumb for all datasets on tape - that to be blocked optimally use X? The lrecls on these tape range from 80 to 10399 Lizette -- 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: Optimal Tape Blocksize
On Thu, 26 Mar 2009 13:22:01 -0400, Lizette Koehler wrote: >I am going to be doing an analysis on our tapes to see if they are optimally blocked. We are using VTS that looks like 3490E tapes. > >Is there a good rule of thumb for all datasets on tape - that to be blocked optimally use X? > >The lrecls on these tape range from 80 to 10399 > >Lizette > For tape (especially modern tape), I've always here that the optimal BLKSIZE is as big as you can make it. For "normal" VB files that would be 32767. For FB files, the largest multiple of the LRECL <= 32767. IIRC, there are some products which can exceed this. But the QSAM/BSAM access method is stuck at 32767. At least until somebody tells me that I am totally out of date, again. -- John -- 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: Optimal Tape Blocksize
Bigger the better, but I just use SDB :) Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Lizette Koehler > Sent: Thursday, March 26, 2009 10:22 AM > To: IBM-MAIN@bama.ua.edu > Subject: Optimal Tape Blocksize > > I am going to be doing an analysis on our tapes to see if they are > optimally blocked. We are using VTS that looks like 3490E tapes. > > Is there a good rule of thumb for all datasets on tape - that to be > blocked optimally use X? > > The lrecls on these tape range from 80 to 10399 > > Lizette > > -- > 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
Optimal Tape Blocksize
I am going to be doing an analysis on our tapes to see if they are optimally blocked. We are using VTS that looks like 3490E tapes. Is there a good rule of thumb for all datasets on tape - that to be blocked optimally use X? The lrecls on these tape range from 80 to 10399 Lizette -- 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
