Re: 3390 Huge Volumes
I greatly appreciate all the information everyone provided. Thank you. Cecelia Dusha
Re: 3390 Huge Volumes
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dusha, Cecelia Ms. WHS/ITMD Sent: Wednesday, May 17, 2006 5:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: 3390 Huge Volumes The 3390 mod 9 are not large enough for the customer's application. What is the largest volume z/VM 5.1 can handle? If only the data utilized the one huge volume, what would be the repercussions? Please advice. Cecelia Dusha IIRC, currently the largest 3390 emulation is one with just a bit less than 64K cylinders. I think that this is about 57 Gb in size. This is an absolute upper limit to the 3390 architecture because the cylinder number is an unsigned half-word. Now, I would ask some futher question. First is, what OS is the application running under? Eg: CMS, z/OS, z/VSE, z/TPF, or z/Linux? In all cases other than CMS, the application should be able to use multiple volumes for its data. In z/Linux, you can create really huge filesystems by using LVM to create large logical volumes which are spread over multiple physical 3390s. So, personally, I'd ask the customer why a really huge single volume is required. There may be a better way than just creating a single super huge 3390. Also, remind them that disaster recovery is complicated by using non standard volume sizes. Also, it is usually much faster, for example, to restore 3 x 3390-3 volumes than 1 x 3390-9 because with the 3390-3, you can restore all three concurrently. The larger the physical 3390 volume, the more time it will take to restore it in a disaster (either remotely or locally!). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.
Re: 3390 Huge Volumes
We have a vg that is 54g in size and it works well. Mace
Re: 3390 Huge Volumes
On Wed, 17 May 2006 10:25:01 -, Dusha, Cecelia Ms. WHS/ITMD [EMAIL PROTECTED] wrote: The 3390 mod 9 are not large enough for the customer's application. What is the largest volume z/VM 5.1 can handle? If only the data utiliz ed the one huge volume, what would be the repercussions? Please advice. Cecelia Dusha = Cecelia, The current limit on 3390 size on your DS6800 is 65520 cylinders. In you r case, running NOMAD, you'll hit the limitation caused by CMS needing to keep all it's file status and control information below 16M in virtual storage. So 32767 cylinders is about the practical limit for a single CM S MDISK. There is some information about this in the z/VM 5.2 CP Planning and Administration manual under the MDISK statement. Not sure if the sam e note is in your 5.1 version of the manual, but it still applies. Repercussions of one large volume in your environment would mostly be los s of I/O concurrency if it is a shared database. Your backup recover y is one big HIDRO stream anyway, so the number of volumes is not a factor. Other considerations would revolve around loss of flexibility from having volumes of different sizes. (eg. you're stuck needing a volume that size when you FLASHCOPY it, move it to a different LCU, go to DR, or make a copy of it for testing.) I don't know NOMAD's capability for spreading it's data across several MDISKS, but it would be very wise to do it if NOMAD can. Eventually the point will be reached where even the largest MDISK will not be enough and then the application is SOL if it can't use multiple MDISKS. So the earlier they use multiple MDISKs the less pain they'll encounter later. Brian Nielsen
Re: 3390 Huge Volumes
What is the largest volume z/VM 5.1 can handle? For CKD, 32767 cylinders. For emulated FBA, I think (no manuals at hand), 384G (you need SCSI support for this). If only the data utilized the one huge volume, what would be the repercussions? Depends on the access patterns in the app. If it's mostly sequential reads, it'd probably be OK. Random access will definitely see some seek queuing.
