EDUCATION.
User education. One should sched some light, explain the user the
complexities of the storage, data netto, data brutto, etc.
BTW:
I have a paper for "upper level management" which explains such
differences. In simple points:
- RAID takes one disk for parity (you pay for N+1 and get N)
- raid group reminder (usually raid group contains integral number of
3390 volumes, maybe some remainder i left = lost)
- on 3390 a 56kB track conains 48kB of DB2 data (12x4kB).
- there is free space at SG level
- there is free space inside of tablespace
- there is secondary copy in DR site
- there are other copies i.e. for test
- last, but not least: 1TB <> 1TiB
Radoslaw Skorupka
Lodz, Poland
W dniu 2012-03-21 15:03, Bill Fairchild pisze:
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 p!
ro!
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
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
