Re: SMS allocation in Cylinders using AMS
When Bill says... You are correct. I was assuming that nobody had (and the original poster had NOT) done anything really inappropriate. For any CISIZE past 16KB you get into diminishing returns on a 3390, capacity-wise. There is almost never any good reason to specify a CISIZE for a LINEAR data set other than 4 KB, especially not when used how they were originally intended to be used: with DIV. Assuming a random access pattern, they work much better, quite a bit more efficiently, meaning less I/O and substantially less CPU, with a 4 KB CISIZE (at least according to my own artificial benchmarks - YMMV). Y'really ought to take him at his word. These artifical benchmarks he has created to test a certain LDS/DIV based component have, over the last few years, beaten the living daylights out of DIV processing to the extent that he can tell you exactly where DIV is spending its time. He even has heuristic algorithms to optimize DIV save processing. It's unlikely anyone outside of system test in Pokey has anything close the insight Bill has into how that puppy works. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
O'Brien, David W. (NIH/CIT) [C] wrote: And when was the last time you used non-3390 geometry? The device independence was important back in the early days of VSAM, circa 1975 when you had 3330s, 3350, 3340s on the floor, which were then followed by 3380s and 3390s. Assuming that 3390 geometry is here to stay at least from a logical Zos perspective, I don't see any downside to using Tracks or Cyls. But then I'm sure someone will disagree. Last but not least: Not every (unit+amount) combination results in cylinder allocation. But when you use cylinders you are *sure* that allocation will result in cylinders. When using tracks or kilobytes or records, there is no such warranty (it depends on the amount). -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
William H. Blair wrote: Arthur T. wrote You don't mention the CI size. He does not need to. Gilbert Cardenas wrote: LINEAR - which means that it will have a CISIZE of 4 KB (4096). There are exactly 180 4K blocks (CIs) in each 3390 CYL. All LINEAR cluster space allocation calculations can be made knowing just that. Not true. However in was true in The Very Old Days. Nowadays CISZ=4k is default for LDS, but not the only choice. It can be any multiplication of 4k: 4,8,12,16,20,24,28,32 kB. So, the assumption above is not safe. -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
Gilbert, What is your device geomtery on your CDS BASE DISPLAY? For 3390 it should be 56664 bytes per track and 15 tracks per cyl. If it were set to 3380, I would expect your allocations to be approx 20% smaller than requested. Where in the manual did it tell you not to use Cyls? I've been using Cyls or Tracks for years with no problem. 43 cyls for 30 MB is about right. Might depend on your Cisize. From: Gilbert CardenasSent: Wed 4/16/2008 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: SMS allocation in Cylinders using AMS Hello everyone, I have an unknown that I have not been able to figure out or at least I don't know where to look. I have a user who is trying to define a vsam file using IDCAMS as follows: DEFINE CLUSTER - ( NAME(BLAH.BLAH.BLAH) - LINEAR - REUSE - CYL(30) - SHAREOPTIONS(3 3) ) - DATA - ( NAME(BLAH.BLAH.BLAH.DATA) - ) - CATALOG(BLAH) The problem is, when I look at the dataset (which is SMS managed) it usually ends up being around 3 times larger than what the user requested. Of course the first place I looked was in the dataclas that this dataset gets assigned and the only thing that the dataclas specifies is a volume count of 1. There are no overrides anywhere else for primary or secondary space. Looking at the Access Method Services documentation, it states that you should not use the TRACKS or CYLINDERS parameters. If you use them for an SMS-managed data set, space is allocated on the volumes selected by SMS in units equivalent to the device default geometry. Could the reason that this dataset is being allocated larger than requested have to do with the fact that the sms volumes are mod 9 volumes? Btw, I tried allocating the dataset in Megabytes (30) and I got 43 cyl with 1 extent. I don't know what the conversion of megabytes to cylinders is but this still doesn't seem right. Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
Additional info, I found out where the default allocation is coming from (CDS base configuration). Apparently, when they setup the SMS default configuration, they setup the default unit to be 3390 and the default bytes per track to be 56665 : Default Management Class : Default Device Geometry : Default Unit . . . . . . : 3390Bytes/track . . . . . : 56665 Tracks/cylinder . . . : 15 The bytes per track is the same for a 3390 mod 3 and 9 (56,664) but is the allocation tripled when a mod 9 is used? On Wed, 16 Apr 2008 12:28:13 -0500, Gilbert Cardenas [EMAIL PROTECTED] wrote: Hello everyone, I have an unknown that I have not been able to figure out or at least I don't know where to look. I have a user who is trying to define a vsam file using IDCAMS as follows: DEFINE CLUSTER - ( NAME(BLAH.BLAH.BLAH) - LINEAR - REUSE - CYL(30) - SHAREOPTIONS(3 3) ) - DATA - ( NAME(BLAH.BLAH.BLAH.DATA) - ) - CATALOG(BLAH) The problem is, when I look at the dataset (which is SMS managed) it usually ends up being around 3 times larger than what the user requested. Of course the first place I looked was in the dataclas that this dataset gets assigned and the only thing that the dataclas specifies is a volume count of 1. There are no overrides anywhere else for primary or secondary space. Looking at the Access Method Services documentation, it states that you should not use the TRACKS or CYLINDERS parameters. If you use them for an SMS-managed data set, space is allocated on the volumes selected by SMS in units equivalent to the device default geometry. Could the reason that this dataset is being allocated larger than requested have to do with the fact that the sms volumes are mod 9 volumes? Btw, I tried allocating the dataset in Megabytes (30) and I got 43 cyl with 1 extent. I don't know what the conversion of megabytes to cylinders is but this still doesn't seem right. Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
I'd also ask if when you see the dataset using 3 times what the user requested, are you looking immediately after it's been defined or after data has been loaded into it? It might be extending once it's populated. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/16/2008 01:52:52 PM: Gilbert, What is your device geomtery on your CDS BASE DISPLAY? For 3390 it should be 56664 bytes per track and 15 tracks per cyl. If it were set to 3380, I would expect your allocations to be approx 20% smaller than requested. Where in the manual did it tell you not to use Cyls? I've been using Cyls or Tracks for years with no problem. 43 cyls for 30 MB is about right. Might depend on your Cisize. From: Gilbert CardenasSent: Wed 4/16/2008 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: SMS allocation in Cylinders using AMS Hello everyone, I have an unknown that I have not been able to figure out or at least I don't know where to look. I have a user who is trying to define a vsam file using IDCAMS as follows: DEFINE CLUSTER - ( NAME(BLAH.BLAH.BLAH) - LINEAR - REUSE - CYL(30) - SHAREOPTIONS(3 3) ) - DATA - ( NAME(BLAH.BLAH.BLAH.DATA) - ) - CATALOG(BLAH) The problem is, when I look at the dataset (which is SMS managed) it usually ends up being around 3 times larger than what the user requested. Of course the first place I looked was in the dataclas that this dataset gets assigned and the only thing that the dataclas specifies is a volume count of 1. There are no overrides anywhere else for primary or secondary space. Looking at the Access Method Services documentation, it states that you should not use the TRACKS or CYLINDERS parameters. If you use them for an SMS-managed data set, space is allocated on the volumes selected by SMS in units equivalent to the device default geometry. Could the reason that this dataset is being allocated larger than requested have to do with the fact that the sms volumes are mod 9 volumes? Btw, I tried allocating the dataset in Megabytes (30) and I got 43 cyl with 1 extent. I don't know what the conversion of megabytes to cylinders is but this still doesn't seem right. Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
On Wed, 16 Apr 2008 13:52:52 -0400, O'Brien, David W. (NIH/CIT) [C] [EMAIL PROTECTED] wrote: snip Where in the manual did it tell you not to use Cyls? I've been using Cyls or Tracks for years with no problem. I was looking at the Access Method Services for Catalogs Chapter 14 page 142. To maintain device independence, do not use the TRACKS or CYLINDERS parameters... Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
On Wed, 16 Apr 2008 13:57:05 -0400, David Betten [EMAIL PROTECTED] wrote: I'd also ask if when you see the dataset using 3 times what the user requested, are you looking immediately after it's been defined or after data has been loaded into it? It might be extending once it's populated. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ It is already bigger after allocation and before the dataset is even populated. Thanks, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
And when was the last time you used non-3390 geometry? The device independence was important back in the early days of VSAM, circa 1975 when you had 3330s, 3350, 3340s on the floor, which were then followed by 3380s and 3390s. Assuming that 3390 geometry is here to stay at least from a logical Zos perspective, I don't see any downside to using Tracks or Cyls. But then I'm sure someone will disagree. From: Gilbert Cardenas [mailto:[EMAIL PROTECTED] Sent: Wed 4/16/2008 2:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMS allocation in Cylinders using AMS On Wed, 16 Apr 2008 13:52:52 -0400, O'Brien, David W. (NIH/CIT) [C] [EMAIL PROTECTED] wrote: snip Where in the manual did it tell you not to use Cyls? I've been using Cyls or Tracks for years with no problem. I was looking at the Access Method Services for Catalogs Chapter 14 page 142. To maintain device independence, do not use the TRACKS or CYLINDERS parameters... Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
On Wed, 16 Apr 2008 14:02:33 -0400, O'Brien, David W. (NIH/CIT) [C] [EMAIL PROTECTED] wrote: And when was the last time you used non-3390 geometry? The device independence was important back in the early days of VSAM, circa 1975 when you had 3330s, 3350, 3340s on the floor, which were then followed by 3380s and 3390s. Assuming that 3390 geometry is here to stay at least from a logical Zos perspective, I don't see any downside to using Tracks or Cyls. But then I'm sure someone will disagree. Actually, I don't disagree either. We have always used tracks/cylinders for allocation and have not had the urge or need to convert to other formats. But considering the current problem I'm having, I wondered if that was the correct decision? Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
Gil, Is it only the one file that you have this problem with? Actually, I don't disagree either. We have always used tracks/cylinders for allocation and have not had the urge or need to convert to other formats. But considering the current problem I'm having, I wondered if that was the correct decision? Regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
On 16 Apr 2008 10:28:21 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Gilbert Cardenas) wrote: Hello everyone, I have an unknown that I have not been able to figure out or at least I don't know where to look. I have a user who is trying to define a vsam file using IDCAMS as follows: DEFINE CLUSTER - ( NAME(BLAH.BLAH.BLAH) - LINEAR - REUSE - CYL(30) - SHAREOPTIONS(3 3) ) - DATA - ( NAME(BLAH.BLAH.BLAH.DATA) - ) - CATALOG(BLAH) The problem is, when I look at the dataset (which is SMS managed) it usually ends up being around 3 times larger than what the user requested. snip Looking at the Access Method Services documentation, it states that you should not use the TRACKS or CYLINDERS parameters. If you use them for an SMS-managed data set, space is allocated on the volumes selected by SMS in units equivalent to the device default geometry. You don't mention the CI size. This is pure guesswork, but it could work like this: CYL(30) is converted to about 25,500,000 bytes. If CI size is 512, you get only 25,088 bytes per track, so that number of bytes requires about 1017 tracks or 68 cylinders. That's not a factor of 3, but it is more than a factor of two. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
On Wed, 16 Apr 2008 14:27:07 -0400, O'Brien, David W. (NIH/CIT) [C] [EMAIL PROTECTED] wrote: Gil, Is it only the one file that you have this problem with? Actually, I don't disagree either. We have always used tracks/cylinders for allocation and have not had the urge or need to convert to other formats. But considering the current problem I'm having, I wondered if that was the correct decision? Regards, Gil. -- I found the problem y'all, the default sms configuration bytes/track was off by one byte (56665 instead of 56664): Default Management Class : Default Device Geometry : Default Unit . . . . . . : 3390Bytes/track . . . . . : 56665 Tracks/cylinder . . . : 15 I saw this earlier but I didn't think it would make such a drastic difference until one of the guys here said that might be the cause. I changed it and reran the jcl and now its working as designed. Thanks for the quick responses, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
Arthur T. wrote You don't mention the CI size. He does not need to. Gilbert Cardenas wrote: LINEAR - which means that it will have a CISIZE of 4 KB (4096). There are exactly 180 4K blocks (CIs) in each 3390 CYL. All LINEAR cluster space allocation calculations can be made knowing just that. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
The following is from the AMS manual concerning CISIZE for Linear datasets: For a linear data set, the size specified is rounded up to 4096 if specified as 4096 or less. It is rounded to the next higher multiple of 4096 if specified as greater than 4096. So a Linear dataset will have a Cisize that is a multiple of 4096, not an absolute value of 4096. From: William H. Blair Sent: Wed 4/16/2008 5:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMS allocation in Cylinders using AMS Arthur T. wrote You don't mention the CI size. He does not need to. Gilbert Cardenas wrote: LINEAR - which means that it will have a CISIZE of 4 KB (4096). There are exactly 180 4K blocks (CIs) in each 3390 CYL. All LINEAR cluster space allocation calculations can be made knowing just that. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS allocation in Cylinders using AMS
David W. O'Brien wrote: So a Linear dataset will have a Cisize that is a multiple of 4096, not an absolute value of 4096. You are correct. I was assuming that nobody had (and the original poster had NOT) done anything really inappropriate. For any CISIZE past 16KB you get into diminishing returns on a 3390, capacity-wise. There is almost never any good reason to specify a CISIZE for a LINEAR data set other than 4 KB, especially not when used how they were originally intended to be used: with DIV. Assuming a random access pattern, they work much better, quite a bit more efficiently, meaning less I/O and substantially less CPU, with a 4 KB CISIZE (at least according to my own artificial benchmarks - YMMV). So, I'll revise my statement to be more academically correct: There are exactly 180 4K blocks (CIs) in each 3390 CYL. All LINEAR cluster space allocation calculations SHOULD be able to be made knowing just that (unless you have, in ignorance, set an inappropriate, inefficient CISIZE, which is usually any value greater than 4 KB, and most certainly anything greater than 16 KB). -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
