John Eells wrote:
<snip>
Of *course* there has to be a key sent to the drive to open an encrypted
file for read or write. Of *course* it takes nonzero time to retrieve
and send each key (for z/OS, since ICSF stores the keys, we probably
have to wait for ICSF to do an I/O to the PKDS in addition to those
needed to do the handshaking with the tape drive).
<snip>
But I think we have to put this into perspective. How long does a small
disk I/O take these days? A few ms? Maybe a bit more for a cache
miss? Add a couple of channel-to-controller transfers at perhaps a
couple more ms. Compare this to the time it takes to mount a tape and
position it to the first file...will you even notice (and could you even
measure) the percentage overhead for the first file? Wouldn't it be
smaller than the variation in tape mount and positioning time for an
ATL? I would think the same goes for the unload time.
<snip>
Having said that, I'm not sure what the delays might be for opening a
large number of small encrypted files once you get past the first one
because I've completely lost track of how the drives to buffering and
tape positioning these days.
<snip>
What I should have added, and forgot to, is that I was only
talking about the key exchange overhead. Exactly how much
overhead there is for the tape drives' encryption operation
itself I don't know but from the little I've heard I think it's
quite small.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
