Yes, that was a typo. We allow 3490 or 3590, but as I said, most define as
3490 and we have only had 1 customer do 3590. The 3590 customer is
international and he does stack data sets on each tape. We are backing up
over 1000 tapes per night at that site.
Ken
Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com
> On May 23, 2018, at 11:39 AM, Mike Baldwin <m...@cartagena.com> wrote:
>
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
