Hi Tony,
Wow, long Friday thread!
Tony, our observation is that customers who choose a VTL that supports 3590
logical device type usually choose to exploit 3590.
A couple of the largest VTL vendors only support 3490, so they have a choice of
one, and it does not seem to be a priority to add 3590 emulation. I hope that
changes, but it's possible that if you change to one of those vendors in
future, you could be changing from 3590 back to 3490!
"All VTLs should be defined as 3490s because that is what everybody does."
Not really, but if choosing 3590 it would be prudent to ensure that the
recovery site also supports 3590.
"if we have an issue with the VTL we can just swap the fiber and continue
running on real 3590s"
I don't hear of this practice. I think redundancy is usually built into the
network (grid) configuration (multiple VTL's).
If doing this, I hope you at least have real TS11x0's (less obsolete than real
3590), and enough of them!
"only define them as 3590 if the customer has a "desire" to define 3490."
I hope that's a typo, Ken! ;-)
"you can define the virtual-volumes in Gigabytes of capacity."
Yes, these days customers are defining their logical volumes on new libraries
at values like 25 GiB, 32 GB, 40 GB
(regardless of the 3490/3590 question).
When we migrate, that greatly reduces the number of multi-volume datasets and
volume chains.
Also, we have seen in larger shops a lot of time can be spent on tape
management house-keeping
and synchronisation of the library with tape management. (Think millions of
those smaller volumes).
Consolidation to fewer, larger logical volumes can save storage management time.
"If you stack lots of very small files, you run into a problem with the
Block-ID not being large enough."
We don't see customers needing to stack many files on logical volumes (I would
define many as thousands).
And,
>> Depending on how the data is accessed, having more blocks on an emulated
>> tape than can be addressed by blkid, may not be a problem. Or, perhaps the
>> emulation uses newer blkid format, and as long as mvs does not manipulate
>> them, they likely work ok.
>> Mike Wood
"it might be better to use 3590 as a base so that there are few virtual tapes
changed [sic]
together. The plus of this is easier tape management."
This benefit (volume chain length) can be achieved with logical volume size,
regardless of 3490/3590 choice. I.e., choose higher capacity -> fewer volumes.
"I don't agree...with the sites that don't specify a limit to the tape size."
In z/OS storage management, we like limits, don't we? I think it's a good
safety catch
that other platforms lack.
"there is no file size limit."
Yes, for practical purposes, there may seem to be no limit, but usually there
is a limit to the
size of a file in the back-end (Unix) filesystem. These days, a cartridge may
contain
20 TB; the SL standard allows over 2 PB per dataset (and 65535 datasets per
volume!)
"VTS is still able to use TS1150 (what about TS1155???), but it is
backend of the VTS, not frontend.
Previously I had a choice: use native drives or buy VTS add-on. Now we have
only VTS."
"for investment protection
IBM United States Hardware Announcement 117-038...
The TS1155 Tape drive is not compatible with IBM TS7700 or Enterprise Tape
Control Unit environments...
Native data rate of 360 MBps...
TS1155 Tape Drive Model 55F is supported in a wide range of environments,
including IBM Power Systems, IBM System i, IBM System p, IBM System x, and
other servers running AIX, Linux, Oracle Solaris, and Microsoft Windows"
(No mention of z/OS, mainframe, or FICON)
I imagine the (millennial?) reader gets the message that for the newest,
fastest, highest capacity
tape subsystem, hooray I can use it with my Windows servers. It should not
even cross my mind
that mainframes still exist, let alone have unique I/O strengths.
IMHO this fuels the daily eyebrows raising "There are still mainframes?"
("There are still tapes?")
<\rant>
"IBM has waited some period of time before certifying z/OS use of that new tape
drive/tape media/density. I suspect that's because IBM is just being that extra
bit careful"
I'm not sure about that, but unlike the following there was no mention of a
plan for TS7700:
"IBM plans to extend support for the TS1155 Tape Drive Model 55F to the IBM
Spectrum Archive family of products."
Maybe we need to read between the lines?
"The auditors are ok with old tapes that most likely will
never need to be read...Management has chosen 'deniability'."
That is disturbing.
"There is absolutely no limitation on continuing to use
physical tape media for your organization's data storage needs."
See above, TS1155 not supported with mainframe. (Except maybe LinuxONE?)
"You do need a tape controller for physical tape. That's always been true"
Technically yes, although some (non-IBM) drives include a built-in controller.
Timothy, thank you for contributing that IBM considers TS7700 the new
tape control unit. Otherwise we think IBM taketh away without THINKing.
Thanks for reading this far! Did I kill the thread?
Regards,
Mike Baldwin
Cartagena Software Limited
Markham, Ontario, Canada
www.cartagena.com
www.teltape.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
