The problem is different people will have different assumptions. What I would do is provide clarification in the documentation of what is being done and how you are measuring data volumes. You may want to put out multiple messages, one an actual amount processed, another with the theoretical and one more for why the difference.
Here are the messages I would put out for a user that used BLKSIZE=30000 for a data set. MSG1000I COPIED 10,000MB OF DATA IN 200.00 SECONDS AT 50.0MB PER SECOND MSG1001I COPIED 333,334 TRACKS IN 200.00 SECONDS AT 94.4MB PER SECOND MSG1002I TRACKS ALLOCATED 333,334 TRACKS USED 333,334 MSG1003I AVERAGE TRACK UTILIZATION - 30,000 BYTES OF 56,664 BYTES OR 52.9% Of course you can tell them all this in the manual and the messages, but if they don't read either there isn't much you can do. Chris Blaicher Senior Software Engineer, Software Services Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: [email protected] www.syncsort.com Check out our Knowledge Base at www.syncsort.com/support Syncsort aims for the best product and service experience. We welcome your feedback. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Fairchild Sent: Wednesday, March 21, 2012 9:03 AM To: MVS List Server 1 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:[email protected]] On Behalf Of Ron Hawkins Sent: Tuesday, March 20, 2012 8:59 PM To: [email protected] 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:[email protected]] On > Behalf Of Bill Fairchild > Sent: Tuesday, March 20, 2012 3:12 PM > To: [email protected] > 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:[email protected]] On > Behalf Of Alan Altmark > Sent: Monday, March 19, 2012 5:39 PM > To: [email protected] > Subject: Re: host codepge 0037 and the obscure "not sign" > > On Tue, 13 Mar 2012 12:51:26 -0400, Shmuel Metz (Seymour J.) > <[email protected]> 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 > [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
