Unsolved
This post is more than 5 years old
207 Posts
0
1211
Connecting z9 to our Open System DMX4
Hello,
I am an open systems guy. Currently we have 2 DMX1000s that are used for open systems. When we get our new DMX4 arrays we will port our open systems but will also connect our IBM mainframe (currently connected to Shark).
On the open systems side we typically have large file systems or Windows partitions. An AIX file system may be 22GB. In this case we would likely use a 4-way or 8-way striped meta to get several spindles involved for performance. In SQL server most of our databases are around 130GB. We might use a 16-way or 24-way striped meta. Or we may use three 8-way striped metas. Lots of spindles helps with performance.
On the open systems side we will likely use split sizes of around 8GB. The mainframe is a source of confusion regarding split size. I believe we use mostly mod3 and mod9s on our Mainframe. Maybe mod27s in the future.
I believe that a mod3 is around 2.8GB. I believe a mod9 is three mod3s. A mod27 is 3 mod9s. Should our split size for the MF be 2.8GB? Or should the split size be a subset or fraction of the 2.8 for example use four .7GB slices to make up one mod3 (.7 * 4 = 2.8)? This would make sure that every mod3 would be spread across 4 disks.
Does anyone know of some good documentation to help an Open Systems guy understand the symm in a ZOS environment? Maybe something that helps explain ZOS DASD environment etc. Apparently we have lots of VSAM files and DB2 databases.
In AIX we have file systems, AIX Logical Volumes and AIX Volume Groups. We add symm devices to the AIX Volume Group and then create AIX logical volumes and file systems from the VG. How does it work on the Z9 side?
Thanks - Brad
I am an open systems guy. Currently we have 2 DMX1000s that are used for open systems. When we get our new DMX4 arrays we will port our open systems but will also connect our IBM mainframe (currently connected to Shark).
On the open systems side we typically have large file systems or Windows partitions. An AIX file system may be 22GB. In this case we would likely use a 4-way or 8-way striped meta to get several spindles involved for performance. In SQL server most of our databases are around 130GB. We might use a 16-way or 24-way striped meta. Or we may use three 8-way striped metas. Lots of spindles helps with performance.
On the open systems side we will likely use split sizes of around 8GB. The mainframe is a source of confusion regarding split size. I believe we use mostly mod3 and mod9s on our Mainframe. Maybe mod27s in the future.
I believe that a mod3 is around 2.8GB. I believe a mod9 is three mod3s. A mod27 is 3 mod9s. Should our split size for the MF be 2.8GB? Or should the split size be a subset or fraction of the 2.8 for example use four .7GB slices to make up one mod3 (.7 * 4 = 2.8)? This would make sure that every mod3 would be spread across 4 disks.
Does anyone know of some good documentation to help an Open Systems guy understand the symm in a ZOS environment? Maybe something that helps explain ZOS DASD environment etc. Apparently we have lots of VSAM files and DB2 databases.
In AIX we have file systems, AIX Logical Volumes and AIX Volume Groups. We add symm devices to the AIX Volume Group and then create AIX logical volumes and file systems from the VG. How does it work on the Z9 side?
Thanks - Brad
Notach
21 Posts
1
May 2nd, 2008 01:00
i've found a EMC paper on dmx4 where you can see capacacity of 3390 you can define on DMX4
http://www.emc.com/collateral/hardware/specification-sheet/c1166-dmx4-ss.pdf
So to define different capacity model like 3390-3 and 3390-9 (for instance), you must know if your VSAM file is bigger thans a standard 3390-3 (2,8 Gb).
For our Production we have only 3390-3 and for dataset bigger than 2,8 Gb , SMS allow to create and use these big dadasets without problem.
Its the same for DB2,and you can use " partition tablespace " to allocate very huge DB2 database and i't better for performance too.
for dasd in z/OS : you can search:
z/OS V1R8 DFSMS Implementing System Managed Storage
on this URL (ibm site)
http://www-03.ibm.com/systems/z/os/zos/bkserv/r9pdf/index.html#dfsms
A better way for basics on I/o storage on this red ibm book :
IBM Redbooks | ABCs of z/OS System Programming Volume 3 (chapter 2 especially)
http://www.redbooks.ibm.com/redbooks.nsf/e9abd4a2a3406a7f852569de005c909f/b8f5c161548c5af5852572a300685bf4?OpenDocument
hope the link is correct. if not search title of redbook on ibm technical site to find the right uRL.
Welcome in mainframe world
brad12341
207 Posts
0
May 2nd, 2008 10:00
Thanks for the info. Chapter 2 and 3 of the ABC's looks pretty good. I think I am starting to understand that the DMX4 will emulate the traditional DASD 3390. I beleive my open systems on the DMX1000 use a track size of 32k and 64k on the new DMX4. It looks like the 3390 uses 56k per track.
After talking more with EMC it looks like we will use .7GB splits so that each mod3 will sit on 4 disks. This should engage enough spindles for each mod3.
I will continue to research how the MF uses DASD and the DMX. When you talk about a zOS "volume" is that same thing as the mod3 or mod9?
smbl
48 Posts
1
May 5th, 2008 02:00
First I would like to send some information abort size mainframe volumes:
General rules for 3390 model - 1CYL=15 TRK, 1 TRK=56664 bytes
3390-1 (1113 CYL)
3390-3 (3339 CYL)
3390-9 (10017 CYL)
3390-27 (32760 CYL)
3390-54 (65520 CYL)
Having this information you can simple calculate size in MB of each emulation and type of volume. Some disks vendors allows you to create CVS (custom volume size). So you can define volumes in variable number of CYL, but the rest of data is the same (1 CYL=15TRK, 1TRK = 56 kb). It is not so popular, most mainframe customers use standard 3390-x volumes.
In mainframe environment we use CKD volumes. There is no one file system like in UNIX or windows. Regarding on type of data sets you can specify blocksize, size of data sets and other internal parameters.
Most of all types of datasets (data sets organizations) can be multivolume. So you don¿t need to worry how to spread data across volumes. If you use DFSMS ¿ you can use data striping too. In this case operating system (in fact DFSMS) is responsible for optimal block size, regularly distribution data across logical volumes, etc
If you use DB2 there are several methods to improve performance I/O. You can use ¿partitioning tablespace¿ as Notah said or/and VSAM striping. In each case if you use DFSMS don¿t care about allocation. System will use all logical volumes in Storage Group.
Last performance problem. If you use PAV feature on DMX and of course this feature is configured in z/OS generally you can use bigger emulation. Without PAV you can expect IOSQ timeouts, specially if you use large volumes with high I/O rate.
Notach
21 Posts
0
May 5th, 2008 06:00
about Z/OS volume, nevermind if it's a 3390-3 or 3390-9, it's a Z/os volume. A 3390-x is a Z/os volume, and we manage all a 3390 dasd.
In our configuration, we have many "vendor volumes" about 1000 cylinder which I use as gatekeeper.
best regards
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
May 5th, 2008 07:00
Right now I'm sitting here, at the window ... And I'm looking and learning .. a lot !!
Interesting thread !!
Message was edited by:
Stefano Del Corno
Davidy8s
154 Posts
0
May 5th, 2008 08:00
http://www.redbooks.ibm.com/abstracts/sg246105.html - VSAM Demystified.
IBM has done a lot recently to accomodate --very-- large VSAM files. So far, the biggest I've seen from a customer was (a total of) 393,091 cylinders which translates 5,896,365 tracks.
Or...
334,111,626,360 bytes, and being updated daily. This was discovered on a software call but I couldn't help but suggest they purchase some more DMX4
Dave Yates
Host S/W Moderator
Message was edited by:
David Yates
brad12341
207 Posts
0
May 9th, 2008 09:00
Apparently this would ensure that open systems could never steal cache resources from the mainframe. This feature is very expensive. Do we really need it? Or will the open systems play nice with the MF? It seems like some customers are mixing open systems and MF without the cache partitioning.
Thanks - Brad
smbl
48 Posts
0
May 12th, 2008 00:00
We use two separate DMX. One for ¿mainframe word¿, second for open system. We¿ve decided for this solution because our mainframe systems are predictable. We know very good what kind of workload we can expect, how we grow each year. Another reason is that mainframe is very ¿cache friendly¿.
In open system (in our case) it is not possible. We don¿t know how many new servers will be connected to the DMX and what kind of workload they will produce.
In your case.
First ¿ try to look at your present workload characteristic, Write/Reads ratio, cache utilization, etc. You can use ECC console and EMC performance monitor for historic data. Maybe it is no problem with cache. Try compare mainframe activity with this data. Mainframe people can deliver some historic date from for example RMF Monitor or other vendors products. Maybe workload peaks in mainframe and open systems are not in the same time ?
You have 64 GB cache and you plan to add only 4 GB cache to mainframe. DMX has many algorithms which don¿t enable to monopolize all cache by one server or monopolize one logical volume. So if you plan only 6% of all cache allocate to mainframe it looks not so dangerous. Last question is: wow important systems you have in a mainframe and what kind of activity they produce (batch, online, etc) ?
Marcin