May be there is a reason as to why you are gettign so many different answers. In my case, the question I normally get from management is: how much is it going to cost us to maintain a copy our application XXX data at our DR location? I change this into a problem of money and budgets. I figured that the biggest variable cost is the network and the disk space. The network also adds other traffic overheads depending on the protocols and recovery but it is highly unlikely that I will get a black and white estimate. The good news about the network is that they sell bandwidth in big jumps so I estimated my worse case scenario by running so tests, made some assumptions (including my data compression), and added the next level of bandwidth (ended up with an OC-12). I gave myself lots of head room because I found that sometimes the equipment doing the compression can fail. The amount of disk was easy, whatever I had needed to be on the other side. In other words, may be the problem that you are trying to solve needs to be revisited. MB/sec is a moving target that can produce as many answers depending on the assumptions you make and who you ask. Regards, Uriel
________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of Bill Fairchild [bfairch...@rocketsoftware.com] Sent: Wednesday, March 21, 2012 10:03 AM To: IBM-MAIN@bama.ua.edu Subject: Re: megabytes per second Everyone is missing the point. Let me rephrase. What do most users and managers think when they hear or use the phrase "copy data at xxx number of MB/sec.?" Do they think that means the theoretically fastest possible rate at which data can be transferred under ideal conditions, or the actual rate at which that user's data can be transferred as that data exists at the instant when the copying is done? Only scenario to consider: an unsophisticated user runs a tool that tells him his data center's mission-critical, home-grown access method file Y has 10,000 MB of data in it. File Y, however, has been allocated to hold 20,000 MB of data. Maybe their home-grown access method does not use DS1LSTAR properly. Maybe DS1LSTAR is maintained but a very inefficient block size is being used. Perhaps the tool reads every track and adds up the block size of all blocks in it. Perhaps the tool looks at the RECFM, BLKSIZE, and device type and computes the size of the contents. The point here is that there is really only 10,000 MB of user data stored in this file that could theoretically hold twice as much data. The backup process has been designed to copy every track in the file. Not knowing that each track in his file is only 50% full of data (inter-record gaps, inefficient block size, not enough data yet in the file to fill up each track completely, whatever), he runs a copy pro! duct that can copy 100MB/sec. and finds that it takes 200 seconds to copy his 10,000 MB of data stored in a 20,000 MB file. He measures the elapsed time by looking at the start and end timestamp in his JES job log as any unsophisticated user would. He wants to know why he is only getting 50MB/sec. of copy speed from his copy process that claims it can copy 100MB/sec from DASD to tape. The worst case scenario is that the file is only allocated and has never been loaded with data. In this case, the actual data transfer rate should be 0 MB/secs., but it would still take 200 seconds to copy the file to tape. Bill Fairchild -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Tuesday, March 20, 2012 8:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: megabytes per second Bill, It can also depend on where you are measuring the throughput: Back end of the disk array - there is additional data to transfer due to the encapsulation of EBCDIV within SCSI FBA blocks FICON - It's a 10 bit byte, so divide the data rate by 8 bits. A 1Gb channel is 1000MB/10=100 GB (yes no little i) Tape Drive - whatever you get after ICRC Virtual Tape Drive - whatever you get after ICRC and De duplication This could be a fun topic. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Bill Fairchild > Sent: Tuesday, March 20, 2012 3:12 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] megabytes per second > > New thread. > > What exactly does "MB/second mean when referring to how much data can > be copied from a DASD to a tape? > > To be more precise, I am not interested in big MB vs. little mib, just > the philosophy. Suppose I have a huge file on a "3390" virtual thing > and I can > copy whole tracks to tape at the rate of 100 MB/sec. Assume the > tracks hold > 50,000 bytes instead of 56,664 to make the math easier. Does 100 MB/sec. > mean that I am copying 2,000 tracks per second? Maybe. What if there > is nothing written on the tracks, but I don't know that until I read > them in and > then write the contents? Of course, there is always at least an R0 on every > track, so they are not completely empty. If all they have written on > them is > R0, am I still transferring data at the rate of 100MB/sec? If each > track were > half full, would my effective data transfer rate be only 50 MB/sec? > > Bill Fairchild > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Alan Altmark > Sent: Monday, March 19, 2012 5:39 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: host codepge 0037 and the obscure "not sign" > > On Tue, 13 Mar 2012 12:51:26 -0400, Shmuel Metz (Seymour J.) > <shmuel+ibm-m...@patriot.net> wrote: > >>Is there any translation table in z/os 1.11 that translates the "NOT > >>SIGN" x'5F' to an ascii x'AC', > > > >These is no ASCII 'AC'X; you really need to know what code pages > >you're using to get a correct translation. > > If you use UCS-2, the NOT SIGN is U+00AC. But you're right, it isn't ASCII, it's > Unicode. > > TYPE U 2 B (big endian Unicode) > TYPE U 2 L (little endian Unicode) > > Also look at SITE UCSHOSTCS. > > Alan Altmark > IBM > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
