Re: megabytes per second

[Anne & Lynn Wheeler]

ronjhawk...@sbcglobal.net (Ron Hawkins) writes:
> I didn't get to work with the 3880-13, but with the 3880-23 I think I recall
> sequential pre-fetch was initially fetching three tracks, using a
> wrap-around buffer to keep track of the last block read and maintaining two
> tracks beyond the last track accessed in cache.
>
> With 3990-3 I think this increased to five tracks, and I have no idea about
> 3990-6 and beyond.

re:
http://www.garlic.com/~lynn/2012d.html#72 megabytes per second
http://www.garlic.com/~lynn/2012d.html#75 megabytes per second
http://www.garlic.com/~lynn/2012d.html#76 megabytes per second

this mentions that sequential detect is new function as of June1996
for 3990-6
ftp://public.dhe.ibm.com/eserver/zseries/zos/vse/pdf3/veioperf.pdf

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler  writes:
> data-transfer channel program. Cache operation was also write
> "store-through" ... aka synchronous to disk ... and no indication that
> 3880 controller would do its own seek operation (to move to different
> track for pre-fetch) independent of what was explicit from some channel
> program.


re:
http://www.garlic.com/~lynn/2012d.html#72 megabytes per second
http://www.garlic.com/~lynn/2012d.html#75 megabytes per second

also
http://www.garlic.com/~lynn/2012d.html#73 Execution Velocity
http://www.garlic.com/~lynn/2012d.html#74 Execution Velocity

at least by 80s, some processors were started to do "store-into" caches
(rather than store-through) for additional performance ...  store
operation happened in cache and write could be done asynchronously at
some later point without involving stalling instructions (with store
operations).

Issue with disk caches (& "store-into" for later writting as opposed to
"store-through") was processor cache&memory data was typically viewed as
ephemeral ... i.e. in power failure, changes weren't expected to
survive. However, for disk caches ... store-into had to wait until there
was (typically redundant) battery-backed &/or flash memory ... since
data written to "disk" was expected to survive power failure (would
survive in cache until power was sufficient to eventually write to
disk).

note that ibm dasd/channel operation use to have peculiar power-failure,
failure mode for a long time. data to be written was in processor memory
and if power failed in the middle of the write operation ... there could
be sufficient power for the disk to complete the write operation ... but
not enough to power processor memory and transfer of data to disk. The
symptoms was that disk would propagate write with all zeros ... and then
write correct error code for the partial zero record (no hardware error
condition).

there were even countermeasure system designs through the 80s that all
physical records were guarenteed to end in non-zero (systeme) data
... what wouldn't be seen by applications ... as a validity check for
power-failure partially valid record with propagated zeros.

FBA drives developed strategy that there was sufficient power and data
to always complete a write operation, once it started. Once all CKD DASD
migrated to simulation on top of FBA (there hasn't been any real CKD
DASD for decades) ... along with various intermediate cache memory
... there problem has been mitigated. misc. past posts mentioning
CKD & FBA
http://www.garlic.com/~lynn/submain.html#dasd

misc. past posts mentioning getting to play disk engineer in bldgs.
14&15
http://www.garlic.com/~lynn/subtopic.html#disk

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[Ron Hawkins]

Lynn,

I didn't get to work with the 3880-13, but with the 3880-23 I think I recall
sequential pre-fetch was initially fetching three tracks, using a
wrap-around buffer to keep track of the last block read and maintaining two
tracks beyond the last track accessed in cache.

With 3990-3 I think this increased to five tracks, and I have no idea about
3990-6 and beyond.

With HDS Arrays the sequential pre-fetch buffering is based on the stripe
length of the underlying parity group and the data length of the start SSCH
that triggers the sequential pre-fetch staging and monitoring. 

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Anne & Lynn Wheeler
> Sent: Wednesday, March 21, 2012 9:05 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] megabytes per second
> 
> ronjhawk...@sbcglobal.net (Ron Hawkins) writes:
> > I'm  afraid sequential pre-fetch kinda of makes your point invalid for
> > sequential IO.
> 
> when ibm first came out with full-track cache (3880-13/sheriff) ... it
> advertised a 90% hit rate ... based on 3380 track, 10 records per track
and
> sequential read, where first sequently read on track would fetch the full
> track ... and then the next 9 sequential reads would already be in cache.
> 
> however, if the application when to full-track buffering ... the same
exact
> application and data would go from 90% hit ratio to zero percent hit ratio
> (effectively each track would be read as a whole, streamed through the
> 3880-13 cache right into processor memory ... and then would have any
> additional cache reference for the track). double "full-track"
> buffering would then overlap retrieval of the following track with the
> processing of the records in the previous track (masking disk retrieval
> latency, aka akin to instruction execution with prefetch &/or out-of-order
> execution to mask processor cache miss latency).
> 
> --
> virtualization experience starting Jan1968, online at home since Mar1970
> 
> --
> 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

Re: megabytes per second

[Anne & Lynn Wheeler]

ronjhawk...@sbcglobal.net (Ron Hawkins) writes:
> I'm  afraid sequential pre-fetch kinda of makes your point invalid for
> sequential IO.

when ibm first came out with full-track cache (3880-13/sheriff) ... it
advertised a 90% hit rate ... based on 3380 track, 10 records per track
and sequential read, where first sequently read on track would fetch the
full track ... and then the next 9 sequential reads would already be in
cache.

however, if the application when to full-track buffering ... the same
exact application and data would go from 90% hit ratio to zero percent
hit ratio (effectively each track would be read as a whole, streamed
through the 3880-13 cache right into processor memory ... and then would
have any additional cache reference for the track). double "full-track"
buffering would then overlap retrieval of the following track with the
processing of the records in the previous track (masking disk retrieval
latency, aka akin to instruction execution with prefetch &/or
out-of-order execution to mask processor cache miss latency).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[R.S.]

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, Sh

Re: megabytes per second

[Blaicher, Christopher Y.]

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=3 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: cblaic...@syncsort.com

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:IBM-MAIN@bama.ua.edu] 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: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

Re: megabytes per second

[Shmuel Metz (Seymour J.)]

In
<77142d37c0c3c34da0d7b1da7d7ca3475...@nwt-s-mbx1.rocketsoftware.com>,
on 03/20/2012
   at 10:12 PM, Bill Fairchild  said:

>What exactly does "MB/second mean when referring to how much data 
>can be copied from a DASD to a tape?

It normally refers to the data that are actually copied, not to data
that are skipped.

>What if there is nothing written on the tracks,

Then that, like short blocks, may slow you down.

>If all they have written on them is R0, am I still transferring 
>data at the rate of 100MB/sec?

The Devil is in the details. Are you copying the R0's? If so, those
data count. If not, not. In either case processing large numbers of
tracks with R0 only will make it harder to maintain 100 MB/s.

>If each track were half full, would my effective data transfer rate
>be only 50 MB/sec?

How many half track are you writing to tape per second? With your
roundoff, 4,000 half tracks per second and 2,000 full tracks per
second are both 100 MB/s.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[Uriel Carrasquilla]

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 copyin

Re: megabytes per second

[Bill Fairchild]

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.) 
>  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 e

Re: megabytes per second

[William Donzelli]

> A real 3390 (do they still exist?

I would certainly like to know if any real 3390s are left. I missed the
boat with saving a 3380/3880, and I fear I have also missed this boat.

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[Ron Hawkins]

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.)
>  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

Re: megabytes per second

[Ron Hawkins]

Chris,

I'm  afraid sequential pre-fetch kinda of makes your point invalid for
sequential IO.

> 
> A real 3390 (do they still exist?) even reading just a R0 from a track
will take as
> long as reading two 27K blocks of data from a track.  A similar problem
exists
> with a 32K blocksize on a 3390.  The reason for this is you just have to
wait for
> the disk to spin.  Years ago we used to calculate how many times the disk
had
> to spin, then determine how long that should take and see how close our
> elapsed actually was to that calculated ideal time.
> 
 
Ron 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[Blaicher, Christopher Y.]

As Radoslaw points out, there are a lot of things to consider.  Personally, I 
count the number of bytes transferred at the program level and divide by the 
time to get the rate.

A real 3390 (do they still exist?) even reading just a R0 from a track will 
take as long as reading two 27K blocks of data from a track.  A similar problem 
exists with a 32K blocksize on a 3390.  The reason for this is you just have to 
wait for the disk to spin.  Years ago we used to calculate how many times the 
disk had to spin, then determine how long that should take and see how close 
our elapsed actually was to that calculated ideal time.

With an emulated 3390, I suspect the transfer rate is probably more consistent 
between the two 27K blocks vs 32K blocks.

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: cblaic...@syncsort.com

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:IBM-MAIN@bama.ua.edu] On Behalf Of 
Bill Fairchild
Sent: Tuesday, March 20, 2012 5:12 PM
To: MVS List Server 1
Subject: 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: megabytes per second

[R.S.]

W dniu 2012-03-20 23:12, Bill Fairchild pisze:

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?


Well, megabyte per second is million bytes transmitted/read/written 
within one second. Nothing more, nothing less.


Remarks:
- For purists: 10^6 is MB, 2^20 is MiB, but it changes nothing in the 
above.


- I think there is no big problem with definition of megabytes 
transferred through some interface/cable.


- Your problem mainly regards "what to do with unused objects". The 
object could be track, block, etc. What to do? IT DEPENDS!
Let's take memory, RAM: there is no "empty" cell in the memory, even 
uninitialized cell/page contain some data, usually trash.
In case of 3390 track - when you perform some kind of physical copy, you 
don't care about empty tracks, VTOCs, you just copy track by track. 
However when you care about "never used" tracks", your copy can run much 
faster because you omit some tracks. That's how EMC TF works. But - does 
the disk work faster? NO! ABSOLUTELY NO! The software works SMARTER.
And that's the answer: the software used to copy data can be smart and 
omit unused parts of data.


Another example: DFSMSdss by default does not copy space in extent past 
EOF. So, for example 1% used 100MB file is really copied as 1MB file. 
Smart, but don't do it for JES2 spool - in this case EOF is misleading, 
you have to specify ALLDATA ALEXCP (one of them actually), and demand 
unused space to be also copied. Reason: you know the unused space is not 
actually unused. However when you specify the above options for 
"regular" datasets, you decide to waste resources, not to use smarter 
method and you probably get worse performance.


BTW: Tape controllers use compression, IBM claims 3:1 compression. So 
100MB/s can be compressed to 30MB/s of physical tape recording speed.


So, in case DASD->TAPE copy you have to specify what do you mean by 
saying 100MB/s.
In "optimistic" version you can backup 1000x100MB file 1% used (1MB of 
data), compressed 3:1 (1000x0.333MB= 333MB). Did you back up 100GB or 333MB?



--
Radoslaw Skorupka
Lodz, Poland


--
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 025237, 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

megabytes per second

[Bill Fairchild]

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.) 
 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