we backing up 3.2 TB.
Recycle isn't running either.
Thank You,
Dave O'Brien
NIH Contractor
From: O'Brien, David W. (NIH/CIT) [C]
Sent: Tuesday, September 28, 2010 9:55 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reports for GB per hour to
. (NIH/CIT) [C]
Sent: 23 September 2010 03:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: Reports for GB per hour to tape
Can anyone suggest a methodology to measure GB per hour written to tape?
Management is seeking to evaluate the additional CPU overhead that s/w
encryption might entail.
IBM's Vo
]
Sent: 23 September 2010 03:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: Reports for GB per hour to tape
Can anyone suggest a methodology to measure GB per hour written to tape?
Management is seeking to evaluate the additional CPU overhead that s/w
encryption might entail.
IBM's Volume mount anal
acNEIL
> Sent: Thursday, September 23, 2010 11:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Reports for GB per hour to tape
>
> >You want to use connect time to figure out MB/sec on FICON?
>
> Never said that!
> Just pointed out what EXCPs can/really do mea
SMF 21 records contain byte counts, compressed and uncompressed,
read and written, with ONLY the dismount time of the tape.
But MXG users can use the MXGTMNT Tape Mount Monitor, which
not only generates an SMF record for each mount of each volser,
with mount start and mount satisfied time stamps,
>You want to use connect time to figure out MB/sec on FICON?
Never said that!
Just pointed out what EXCPs can/really do mean.
I'm well aware of the issues with FICON.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!
-
IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Reports for GB per hour to tape
>
> >The EXCP*BLKSIZE=MB is not true for all access methods. I'd only assume
this
> is correct for SAM-E, which is probably the majority of tape IO.
>
> Ron, we've had this argument/discussio
>The EXCP*BLKSIZE=MB is not true for all access methods. I'd only assume this
>is correct for SAM-E, which is probably the majority of tape IO.
Ron, we've had this argument/discussion before.
With XA/ESA, or even slightly before, IOC was changed to allow either blocks or
8.3 ms of connect time.
t; Sent: Thursday, September 23, 2010 6:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Reports for GB per hour to tape
>
> On 23 Sep 2010 07:29:51 -0700, in bit.listserv.ibm-main you wrote:
>
> >Hi John,
> >
> > Yes, I had thought of extrapolati
;Dave O'Brien
>NIH Contractor
>
>From: McKown, John [john.mck...@healthmarkets.com]
>Sent: Thursday, September 23, 2010 10:25 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Reports for GB per hour to tape
>
>> -Original Message-
>> From: IBM Main
In addition to the overhead of software encryption, consider the effects
of the loss of hardware compression for the data written to tape, which
will affect both tape performance and thus elapsed time and the amount
of tape used. Both effects might pose challenges for jobs that need to
finish
Thanks Ron, I see what you're referring to.
Thank You,
Dave O'Brien
NIH Contractor
From: Ron Hawkins [ron.hawkins1...@sbcglobal.net]
Sent: Thursday, September 23, 2010 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reports for GB per hour to t
"O'Brien, David W. [C] , NIH/CIT" wrote in
message
news:..
.
> Can anyone suggest a methodology to measure GB per hour written to
tape?
>
> Management is seeking to evaluate the additional CPU overhead that s/w
encryption might entail.
>
> IBM's Volume mount analyzer gives tape allocation and t
day, September 23, 2010 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Reports for GB per hour to tape
>
> Hi John,
>
> Yes, I had thought of extrapolating channel busy % but I'm not sure that
> would be precise enough.
> Thanks for the suggestion.
&
ptember 23, 2010 10:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reports for GB per hour to tape
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W.
> (NIH/CIT) [C]
> Sent: Thursday, September 2
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W.
> (NIH/CIT) [C]
> Sent: Thursday, September 23, 2010 9:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Reports for GB per hour to tape
&g
: Thursday, September 23, 2010 10:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reports for GB per hour to tape
Dave,
It's rough, but if you have RMM as your tape management system, it records how
much data is written to the tape - precompression. You could just divide the
amount on the tape wi
O'Brien, David W. (NIH/CIT) [C] pisze:
Can anyone suggest a methodology to measure GB per hour written to tape?
Management is seeking to evaluate the additional CPU overhead that s/w
encryption might entail.
IBM's Volume mount analyzer gives tape allocation and tape mounts per hour but
not, t
ld or not.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
O'Brien, David W. (NIH/CIT) [C]
Sent: Thursday, September 23, 2010 8:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Reports for GB per hour to tape
Can anyone suggest a methodolo
Can anyone suggest a methodology to measure GB per hour written to tape?
Management is seeking to evaluate the additional CPU overhead that s/w
encryption might entail.
IBM's Volume mount analyzer gives tape allocation and tape mounts per hour but
not, to my knowledge, GB written per hour.
Yes
20 matches
Mail list logo
