Re: VTL as 3490 vs 3590

[Vernooij, Kees (ITOPT1) - KLM]

Ah yes, it's Friday
Wikipedia: Keep on truckin' is a phrase from the 1930s song "Trucking My Blues 
Away" by Blind Boy Fuller.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Baldwin
> Sent: 25 May, 2018 16:29
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTL as 3490 vs 3590
> 
> On Wed, 23 May 2018 13:02:24 +0800, Timothy Sipples <sipp...@sg.ibm.com>
> wrote:
> 
> >Please keep on trucking!
> 
> It's Friday: I'm not sure where Timothy picked this up, I think he is
> too young to remember this popular expression.
> Eddie Kendricks, RIP.
> 
> Regards,
> Mike Baldwin
> Cartagena Software Limited
> Markham, Ontario, Canada
> http://www.cartagena.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: VTL as 3490 vs 3590

[Mike Baldwin]

On Wed, 23 May 2018 13:02:24 +0800, Timothy Sipples  wrote:

>Please keep on trucking!

It's Friday: I'm not sure where Timothy picked this up, I think he is too young 
to remember this popular expression.
Eddie Kendricks, RIP.

Regards,
Mike Baldwin
Cartagena Software Limited
Markham, Ontario, Canada
http://www.cartagena.com

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

Re: VTL as 3490 vs 3590

[Timothy Sipples]

Rex Pommier wrote:
>Can I force, for example, a set of system backups to get
>sent immediately to the passthru tapes as well as the
>virtual tapes on the TS7720 itself so I can send a set
>of physicals offsite like I do today?

First, a disclaimer: please check with a true storage specialist to confirm
everything. I minor in the subject.

To my knowledge the answer is yes. I'll point to a couple references
that'll help explain the various permutations. First, this 2015 SHARE
presentation is quite helpful:

https://share.confex.com/share/125/webprogram/Handout/Session17963/Share%202015%20Orlando%20-%20TS7720T%20Tape%20Attach%20Deep%20Dive.pdf

In the scenario you describe you'd most likely define both a primary pool
and a secondary pool, use both, and the secondary pool would be "Copy
Exported." The restore process is called "Copy Export Recovery." IBM has
published a rather comprehensive guide on Copy Export features, available
here:

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101092

One important caveat: "Copy Export Recovery" restores to a TS7700T (the "T"
means with physical tape) at the same or higher release level, and of
course with physical media read compatibility. So you need the smart
controller in the restore path. It's virtualized-physical, not
physical-physical, remember. If you still need a barebones restore
capability for media written via your 3592-C06 then one possible approach
is to keep your 3592-C06 for a period of time but attach it to a single
tape drive. The rest of your gear, including your library, move to TS7700
attachment. So if you've got to write a physical-physical tape that
somebody with a 3592-C0x/TS11xx combination needs to read (like you), you
can still do that. Of course you won't want to stay with that vestigial
equipment forever.

I believe it's also possible to "stretch" the distance between your TS7700
and your TS3500, if that sort of approach is helpful. I don't think it's
too sensitive to distance (please check), but you need a suitable
connection with enough bandwidth and reliability, and probably with DWDM
equipment to make that hop. Or for that matter you can "stretch" both
together to a remote site. That's still a fairly popular way to get data
moved off-site, simply to push the tape/virtual tape off at "arms length"
in the distance. As yet another option, you could adopt IBM Cloud Tape
Connector for z/OS in conjunction with your TS7700 (in TS7700T
configuration or not) and use CTC to run backups into (encrypted) cloud
storage off-site. It could be off-site public cloud storage (storage
protocols: IBM Cloud Object Storage or Amazon S3) or second-site/private
cloud storage meeting the same storage protocol standards.

>In the case of backups that need to go offsite, what manages
>the physical tapes in the 3584 - is it still my tape
>management system on the mainframe or is it some kind of
>tape management in the 7720?

It's some of both, but it's mostly your TS7720. On the z/OS side you have
at least a couple tape pools for your scenario, and you'd have either/both
automatic and manual selection of pool(s). Your TS7720 pretty much takes it
from there.

>Can I use other physical tapes in the 3584 as extra space
>for "throwaway" data in the 7720 if I'm running low on cache
>(physical disk) in the VTS?

Absolutely, and that's a common reason for having physical tape. You can
use either/both the "Disk Cache to Tape Content" (CPx/PG1) or "Delayed to
Tape Content" (CPx/delayed premigration) approaches. "Delayed premigration"
means certain volatile data, such as "scratch" datasets, never makes it to
physical tape. Which may or may not be the behavior you want, but it's
available and quite often handy.

>If I'm using some physicals as just cache extension what
>manages these tapes?  Does the 7720 or is this still z/OS
>TMS?  What handles recycling of these tapes?

It's almost all in the TS7700. I say "almost" because there are certainly
z/OS-based controls for how you're managing storage, such as z/OS DFSMShsm
(ML2, etc.)


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

What, z/VM doesn't have 1052-7 support? GD


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
R.S. <r.skoru...@bremultibank.com.pl>
Sent: Tuesday, May 22, 2018 4:03 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

W dniu 2018-05-22 o 19:41, Seymour J Metz pisze:
> 3210 and 3215 are local non-SNA devices; there is no telnet equivalent.

3215?
Is it the $#$@% mode which is widely present in z/VM?
I hate set conmode or how it was...

BTW: 3215 support is optional feature of OSA-ICC. Quite new feature...
It seem someone need it.

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
http://secure-web.cisco.com/1pJSsN96Rikm63Vj5LHNJ-SX67nA5WLPX1cFtkzwpzuCmhax-mMFO5H2fDvYC4xh4oIYDL5cB8IVWjgwODziC_0K74cEJvhsYVRkREg1w93hmI_41FHIxGyMjecX8qGmFS6VPcRmCHZ3A6gibeQnW71w3kYSJBVMnOlyBzoJN3klvFNbm5ayGzRHGwzPz8fK1-mo1XuY_aJ8vSlMopPzGkNrVzp-hEOY78HkWvyLjWvVLONgDdOeTF-tmltqzyINXBz6Y6qwVKK4ioYk4udkiqc2igfT5A1ooW4ylJFC7p-EvbA1rTXjYZqgdtEFRU0Ggoe8F_GjWl2cshh4M5B7Dnv_o01Fjcv4M_F0TNJfK-XE7540xsM5N4O-DnvQ003WPdr5X7gArRLEpXTAKDyW1wybJRvRa71E6KODxZkp0ifVZXoebipTf115ln8QWFpVn/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


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

Re: VTL as 3490 vs 3590

[Ken Bloom]

You make some good points.  Here are a few more things to consider.

Most vendors use .AWS format so there is compatibility at that level and that’s 
useful.  We have conversion utilities that allow us to replace another vendors 
VTL with the 5990.   As a wise person once said "indecision is the key to 
flexibility" which is why we also have the capability to limit volume size.  We 
actually have 1 customer that is runningit hurts to say it 3480 (which we 
also emulate) and we limit the volume size there for him. We find that most 
sites for whatever reason use 3490 with no max volume size even though we 
provide the capability to do other emulation and limit size.  Some sites do 
stack tapes and others put 1 dataset on a tape even though it’s a very small 
data set.  With VTL there is no wasted space so small datasets on a tape is not 
an issue.  
I believe that HSM will limit writing a tape to 97% (default value) of the 
specified tape type, so having unlimited volume size does not really affect 
anything.

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc 
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 23, 2018 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTL as 3490 vs 3590

W dniu 2018-05-23 o 17:39, Mike Baldwin pisze:
[...]
 > Thanks for reading this far! Did I kill the thread?
No! Not at all.

 > A couple of the largest VTL vendors only support 3490
Well, can we enumerate the VTL vendors? IMHO all of them would be happy 
to see its name on the list, while it's still no advertisement.
Let me begin:
IBM TS7700 - does it support 3590 emulation? What volume sizes available?
VISARA Vi-5990 - according to Ken's informaton it does support 3590 
emulation, any volume size.
STK/Oracle VSM - only 3490?
EMC DLm - ???
what else?


Another thread:
Assuming maximum virtual volume size does NOT depend on emulation type 
(which is a case for VISARA) - what is an advantage of having 3590 over 
3490? And the opposite - what's wrong with 3590 emulation?

Compatibility: since both emulated 3490 and emulated 3590 are VIRTUAL 
and exist only inside VTL what problems could happen with "incompatible" 
drives? IMHO VISARA 150GB virtual volume is incompatible with Oracle VSM 
virtual volume despite of emulation type, however in any case it is 
perfectly possible to move data from one tape system to another. The 
largest (actual) volume size matter.


Optimal maximum volume size for HSM:
There are some limitations in HSM which do not allow to backup very 
large datasets because maximum number of tapes used for dump is limited 
to 254 (it was 40 in the past!). That clearly say the small volume size 
could pain.
What about upper values? Is it good or bad to have huge volumes? I'm 
using 4/12TB volumes (real TS1140) and see nothing wrong with it. Of 
course I cannot make the volume smaller4 times (yes, I know there are 
sport cartridges, but I have normal ones).
Getting back to VTLs - what would be wrong in using (potential) 12TB 
virtual volumes for HSM?
I do not insist on 12TB, but I'm trying to understand what the optimal 
value is and why.



Regards
-- 
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rej

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-23 o 17:39, Mike Baldwin pisze:
[...]
> Thanks for reading this far! Did I kill the thread?
No! Not at all.

> A couple of the largest VTL vendors only support 3490
Well, can we enumerate the VTL vendors? IMHO all of them would be happy 
to see its name on the list, while it's still no advertisement.

Let me begin:
IBM TS7700 - does it support 3590 emulation? What volume sizes available?
VISARA Vi-5990 - according to Ken's informaton it does support 3590 
emulation, any volume size.

STK/Oracle VSM - only 3490?
EMC DLm - ???
what else?


Another thread:
Assuming maximum virtual volume size does NOT depend on emulation type 
(which is a case for VISARA) - what is an advantage of having 3590 over 
3490? And the opposite - what's wrong with 3590 emulation?


Compatibility: since both emulated 3490 and emulated 3590 are VIRTUAL 
and exist only inside VTL what problems could happen with "incompatible" 
drives? IMHO VISARA 150GB virtual volume is incompatible with Oracle VSM 
virtual volume despite of emulation type, however in any case it is 
perfectly possible to move data from one tape system to another. The 
largest (actual) volume size matter.



Optimal maximum volume size for HSM:
There are some limitations in HSM which do not allow to backup very 
large datasets because maximum number of tapes used for dump is limited 
to 254 (it was 40 in the past!). That clearly say the small volume size 
could pain.
What about upper values? Is it good or bad to have huge volumes? I'm 
using 4/12TB volumes (real TS1140) and see nothing wrong with it. Of 
course I cannot make the volume smaller4 times (yes, I know there are 
sport cartridges, but I have normal ones).
Getting back to VTLs - what would be wrong in using (potential) 12TB 
virtual volumes for HSM?
I do not insist on 12TB, but I'm trying to understand what the optimal 
value is and why.




Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Ken Bloom]

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

Re: VTL as 3490 vs 3590

[Mike Baldwin]

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 

Re: [External] Re: VTL as 3490 vs 3590

[Pommier, Rex]

I've been following this thread with some interest.  We currently have a TS7720 
without tape behind it and a TS3584 with C06 "dumb" controllers as Timothy 
calls them.  Due to the impending demise of support for the C06 and the 
unavailability of C07 controllers we have decided to swing the 3584 behind the 
7720.  Today when I perform system backups, I send 1 copy to the VTS for ease 
of recovery for the "something happened to my dataset" and the other copy 
directly to the 3592 tapes in the 3584.  This set of backups is transported 
offsite for actual disaster recovery. So here are my questions.  

I was under the impression that the physical tape on the back end of a TS77xx 
box basically acted as a cache extension where the physical tapes were managed 
by the TS77xx controllers.  Can I force, for example, a set of system backups 
to get sent immediately to the passthru tapes as well as the virtual tapes on 
the TS7720 itself so I can send a set of physicals offsite like I do today?  

In the case of backups that need to go offsite, what manages the physical tapes 
in the 3584 - is it still my tape management system on the mainframe or is it 
some kind of tape management in the 7720?

Can I use other physical tapes in the 3584 as extra space for "throwaway" data 
in the 7720 if I'm running low on cache (physical disk) in the VTS?  

If I'm using some physicals as just cache extension what manages these tapes?  
Does the 7720 or is this still z/OS TMS?  What handles recycling of these 
tapes?  

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, May 22, 2018 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: VTL as 3490 vs 3590

W dniu 2018-05-22 o 08:04, Timothy Sipples pisze:
> Radoslaw Skorupka wrote:
>> It is really nice sales pitch, but *technically* IBM it is no longer
>> possible to write directly to a tape volume from z/OS.
> First of all, it's not a sales pitch. I don't do sales pitches very well.
>
> Second, it's also no longer possible to "write directly" to disk drives.
> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
> highly virtualized, with intelligent controllers equipped with caches.
>
> Why is this progress a problem? And it's a very long arc of progress, not
> at all sudden. As I've carefully and accurately documented, there was
> nearly 19 years of product overlap as IBM tape made the transition to
> virtualized-physical.
>
> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
> attachment to your IBM TS7700. I have no inside information on that, but I
> do pay some attention to IBM's past practices.

I was talking to IBMer storage salesmen last week or so. They still 
offer TS1150, not 1155.

Regarding the sales pitch: can I insert physical cart into TS7700? Let's 
imagine I want to write the tape in shop A and read it in shop B.
Yes, I know about grid or even ftp, but I want to send physical medium. 
Just because. Can I?
Or still available ServerPac on a tape. Can it be read on TS7700?

Regards
-- 
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88.

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-23 o 08:19, Brian Westerman pisze:

Except that now you can merely transmit the data to any other server to have it 
offsite.  Having gone through all of the various gyrations over the years of 
trying to come up with ways to get the tapes off site, from paying a company to 
cart them away to the caves to transmitting tape-to-tape at another location, 
trasmitting the data from the back end to another server is (in my opinion) 
much easier.

Yes ...and no.
For regular process yes. Assuming you have to send huge amount of data 
to "foreign" company  - it can be easier to send (encrypted) cart. Last, 
but not least - installation material is an example when we do not care 
to much about data secrecy, but "external media" is something we like.
Of course my example was just to show we lost some functionality with 
lack of support of native tapes.


Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Brian Fraser]

And safer, especially in areas where there are regulators that get very
cranky if a tape goes missing during transit.

On Wed, May 23, 2018 at 2:19 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Except that now you can merely transmit the data to any other server to
> have it offsite.  Having gone through all of the various gyrations over the
> years of trying to come up with ways to get the tapes off site, from paying
> a company to cart them away to the caves to transmitting tape-to-tape at
> another location, trasmitting the data from the back end to another server
> is (in my opinion) much easier.
>
> Brian
>
> --
> 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

Re: VTL as 3490 vs 3590

[Parwez Hamid]

3215 support is a FUNCTION of CHPID = OSC and has been around since 2008. It 
requires the OSA-1000BASE-T feature and main users are z/TPF customers.

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

Re: VTL as 3490 vs 3590

[R.S.]

"...and my car has 4 beautiful wheels including spare one"
(sales pitch in tire workshop)

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Brian Westerman]

Except that now you can merely transmit the data to any other server to have it 
offsite.  Having gone through all of the various gyrations over the years of 
trying to come up with ways to get the tapes off site, from paying a company to 
cart them away to the caves to transmitting tape-to-tape at another location, 
trasmitting the data from the back end to another server is (in my opinion) 
much easier.

Brian

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

Re: VTL as 3490 vs 3590

[Tony Thigpen]

> More: YOU HAVE TO KEEP YOUR VALUABLE ARCHIVE DATA ON NEW MEDIA!
Not really. The auditors are ok with old tapes that most likely will 
never need to be read. If we try to copy it to new media, and it fails, 
then we will know for sure that the tapes are bad and have no option but 
report such to the auditors and get a bad mark on the audit. Management 
has chosen 'deniability'.


> when you use HSM for managing the data

Now, there is the rub. One one of the systems I manage actually have HSM 
managing the data. And, several years ago, someone turned off 
auto-archving and now we have a strong concern about what will happen if 
we turn it back on. So far, we have not had the time to go back and 
research all the settings. :-(


Tony Thigpen

R.S. wrote on 05/22/2018 03:55 PM:

While I still miss native tapes, I see your example as partially invalid.
You can have 20 years old data on ne media, including virtual tapes.
More: YOU HAVE TO KEEP YOUR VALUABLE ARCHIVE DATA ON NEW MEDIA!
Old data, but fresh media.
Reasons:
1. Old tape can be become defective. Of course second copy ...also is
gettind older and older.
2. Old tape need old drive. New tape (or other media) means new
(supported) drive.

Things are quite simple when you use HSM for managing the data. Natural
recycling process will move the data from medium to medium, especially
during imlementation of new hardware. Even without it you can track old
carts and enforce recycling.




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

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-22 o 19:41, Seymour J Metz pisze:

3210 and 3215 are local non-SNA devices; there is no telnet equivalent.


3215?
Is it the $#$@% mode which is widely present in z/VM?
I hate set conmode or how it was...

BTW: 3215 support is optional feature of OSA-ICC. Quite new feature...
It seem someone need it.

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-22 o 08:04, Timothy Sipples pisze:

Radoslaw Skorupka wrote:

It is really nice sales pitch, but *technically* IBM it is no longer
possible to write directly to a tape volume from z/OS.

First of all, it's not a sales pitch. I don't do sales pitches very well.

Second, it's also no longer possible to "write directly" to disk drives.
*All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
highly virtualized, with intelligent controllers equipped with caches.

Why is this progress a problem? And it's a very long arc of progress, not
at all sudden. As I've carefully and accurately documented, there was
nearly 19 years of product overlap as IBM tape made the transition to
virtualized-physical.

Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
attachment to your IBM TS7700. I have no inside information on that, but I
do pay some attention to IBM's past practices.


I was talking to IBMer storage salesmen last week or so. They still 
offer TS1150, not 1155.


Regarding the sales pitch: can I insert physical cart into TS7700? Let's 
imagine I want to write the tape in shop A and read it in shop B.
Yes, I know about grid or even ftp, but I want to send physical medium. 
Just because. Can I?

Or still available ServerPac on a tape. Can it be read on TS7700?

Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[R.S.]

While I still miss native tapes, I see your example as partially invalid.
You can have 20 years old data on ne media, including virtual tapes.
More: YOU HAVE TO KEEP YOUR VALUABLE ARCHIVE DATA ON NEW MEDIA!
Old data, but fresh media.
Reasons:
1. Old tape can be become defective. Of course second copy ...also is 
gettind older and older.
2. Old tape need old drive. New tape (or other media) means new 
(supported) drive.


Things are quite simple when you use HSM for managing the data. Natural 
recycling process will move the data from medium to medium, especially 
during imlementation of new hardware. Even without it you can track old 
carts and enforce recycling.



--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-05-22 o 12:34, Tony Thigpen pisze:

Timothy,

The biggest problem is that physical tape, unlike dasd, has been the 
primary method of data archive and data transport since it was 
created. (And that includes paper tape.) While tape virtualization is 
great for internal tapes, off-site archival now requires an expensive 
duplicate of the primary VTL. And, as machine age and are replaced, 
historical archival have to be converted to the new equipment.


Also, I could always point to the tape rack and tell the auditors: 
"You want the data from 20 years ago? There it is."


Tony Thigpen

Timothy Sipples wrote on 05/22/2018 02:04 AM:

Radoslaw Skorupka wrote:

It is really nice sales pitch, but *technically* IBM it is no longer
possible to write directly to a tape volume from z/OS.


First of all, it's not a sales pitch. I don't do sales pitches very 
well.


Second, it's also no longer possible to "write directly" to disk drives.
*All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
highly virtualized, with intelligent controllers equipped with caches.

Why is this progress a problem? And it's a very long arc of progress, 
not

at all sudden. As I've carefully and accurately documented, there was
nearly 19 years of product overlap as IBM tape made the transition to
virtualized-physical.

Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
attachment to your IBM TS7700. I have no inside information on that, 
but I

do pay some attention to IBM's past practices. What I see is that, for
several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the 
world's

most important financial records) and its long-term retention needs, but
ask.




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

AFAIK, SMCS was limited to 3270, which would give you TN3270 but not line-mode 
telnet. Neither 3210 nor 3215 was supported by VTAM.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Tuesday, May 22, 2018 1:45 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

On Tue, May 22, 2018 at 12:42 PM Seymour J Metz <sme...@gmu.edu> wrote:

> 3210 and 3215 are local non-SNA devices; there is no telnet equivalent.
>

​Hum, how about an LU1 console? I guess I could use c3270 to script an SMCS
console. But, that's more work {frown}. Guess I'm stuck with CA-OPS/MVS,
which is really quite nice.​



>
> "ncurses, foiled again" (GD)
>
>
--
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: VTL as 3490 vs 3590

[John McKown]

On Tue, May 22, 2018 at 12:42 PM Seymour J Metz  wrote:

> 3210 and 3215 are local non-SNA devices; there is no telnet equivalent.
>

​Hum, how about an LU1 console? I guess I could use c3270 to script an SMCS
console. But, that's more work {frown}. Guess I'm stuck with CA-OPS/MVS,
which is really quite nice.​



>
> "ncurses, foiled again" (GD)
>
>
-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

3210 and 3215 are local non-SNA devices; there is no telnet equivalent.

"ncurses, foiled again" (GD)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Tuesday, May 22, 2018 1:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

On Tue, May 22, 2018 at 11:30 AM Seymour J Metz <sme...@gmu.edu> wrote:

> I have a warped mind: I keep thinking of an RFE for z/OS support of
> perforated paper (well, mylar) tape. GD
>

​On a similar note: I want my 3215 console back!

Why? Because I want to be able to have a "line mode" telnet environment
which is a console. That would make it easier to have an "off platform"
automation; perhaps using "expect" to receive console messages and issue
commands. Just another of one of my many weird ideas.​


>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>

--
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: VTL as 3490 vs 3590

[John McKown]

On Tue, May 22, 2018 at 11:30 AM Seymour J Metz  wrote:

> I have a warped mind: I keep thinking of an RFE for z/OS support of
> perforated paper (well, mylar) tape. GD
>

​On a similar note: I want my 3215 console back!

Why? Because I want to be able to have a "line mode" telnet environment
which is a console. That would make it easier to have an "off platform"
automation; perhaps using "expect" to receive console messages and issue
commands. Just another of one of my many weird ideas.​


>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>

-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

IOCP? Can't you do that from PC-readable media these days?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Edward Gould <edgould1...@comcast.net>
Sent: Tuesday, May 22, 2018 2:34 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

> On May 22, 2018, at 1:04 AM, Timothy Sipples <sipp...@sg.ibm.com> wrote:
>
> Radoslaw Skorupka wrote:
>> It is really nice sales pitch, but *technically* IBM it is no longer
>> possible to write directly to a tape volume from z/OS.
>
> First of all, it's not a sales pitch. I don't do sales pitches very well.
>
> Second, it's also no longer possible to "write directly" to disk drives.
> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
> highly virtualized, with intelligent controllers equipped with caches.
>
> Why is this progress a problem? And it's a very long arc of progress, not
> at all sudden. As I've carefully and accurately documented, there was
> nearly 19 years of product overlap as IBM tape made the transition to
> virtualized-physical.
>
> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
> attachment to your IBM TS7700. I have no inside information on that, but I
> do pay some attention to IBM's past practices. What I see is that, for
> several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the world's
> most important financial records) and its long-term retention needs, but
> ask.

Timothy,
I disagree about your sales pitches a little. You do do them but not as blatant 
as others.
I am wondering about your descriptions a little, from several perspectives IBM 
is cutting their head off.
I have had about 5 times in my life as a sysprog, where various utilities 
*FROM* IBM absolutely needed a stand alone tape drive, i.e. one you had to 
mount a physical tape to do say a stand alone restore and the other function I 
needed was to supply the CE with a IOCP deck that was needed for a new system 
(fresh from IBM). There were others which I have done in mostly the middle of 
the night (one or two was with IBM[’s blessing).
I know its not an ever day occurrence but the point is you still need a 
physical tape drive.
I am attempting to remember other utility type functions that a physical tape 
was needed but it is late.
Ed


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

Re: VTL as 3490 vs 3590

[Seymour J Metz]

I have a warped mind: I keep thinking of an RFE for z/OS support of perforated 
paper (well, mylar) tape. GD


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Thigpen <t...@vse2pdf.com>
Sent: Tuesday, May 22, 2018 6:34 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VTL as 3490 vs 3590

Timothy,

The biggest problem is that physical tape, unlike dasd, has been the
primary method of data archive and data transport since it was created.
(And that includes paper tape.) While tape virtualization is great for
internal tapes, off-site archival now requires an expensive duplicate of
the primary VTL. And, as machine age and are replaced, historical
archival have to be converted to the new equipment.

Also, I could always point to the tape rack and tell the auditors: "You
want the data from 20 years ago? There it is."

Tony Thigpen

Timothy Sipples wrote on 05/22/2018 02:04 AM:
> Radoslaw Skorupka wrote:
>> It is really nice sales pitch, but *technically* IBM it is no longer
>> possible to write directly to a tape volume from z/OS.
>
> First of all, it's not a sales pitch. I don't do sales pitches very well.
>
> Second, it's also no longer possible to "write directly" to disk drives.
> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
> highly virtualized, with intelligent controllers equipped with caches.
>
> Why is this progress a problem? And it's a very long arc of progress, not
> at all sudden. As I've carefully and accurately documented, there was
> nearly 19 years of product overlap as IBM tape made the transition to
> virtualized-physical.
>
> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
> attachment to your IBM TS7700. I have no inside information on that, but I
> do pay some attention to IBM's past practices. What I see is that, for
> several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the world's
> most important financial records) and its long-term retention needs, but
> ask.
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
> Multi-Geography
> E-Mail: sipp...@sg.ibm.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

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

Re: VTL as 3490 vs 3590

[Brian Fraser]

-   Also, I could always point to the tape rack and tell the auditors: "You
want the data from 20 years ago? There it is."

But less chance that they could actually read the data.

On Tue, May 22, 2018 at 6:34 PM, Tony Thigpen  wrote:

> Timothy,
>
> The biggest problem is that physical tape, unlike dasd, has been the
> primary method of data archive and data transport since it was created.
> (And that includes paper tape.) While tape virtualization is great for
> internal tapes, off-site archival now requires an expensive duplicate of
> the primary VTL. And, as machine age and are replaced, historical archival
> have to be converted to the new equipment.
>
> Also, I could always point to the tape rack and tell the auditors: "You
> want the data from 20 years ago? There it is."
>
> Tony Thigpen
>
>
> Timothy Sipples wrote on 05/22/2018 02:04 AM:
>
>> Radoslaw Skorupka wrote:
>>
>>> It is really nice sales pitch, but *technically* IBM it is no longer
>>> possible to write directly to a tape volume from z/OS.
>>>
>>
>> First of all, it's not a sales pitch. I don't do sales pitches very well.
>>
>> Second, it's also no longer possible to "write directly" to disk drives.
>> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
>> highly virtualized, with intelligent controllers equipped with caches.
>>
>> Why is this progress a problem? And it's a very long arc of progress, not
>> at all sudden. As I've carefully and accurately documented, there was
>> nearly 19 years of product overlap as IBM tape made the transition to
>> virtualized-physical.
>>
>> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
>> attachment to your IBM TS7700. I have no inside information on that, but I
>> do pay some attention to IBM's past practices. What I see is that, for
>> several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the
>> world's
>> most important financial records) and its long-term retention needs, but
>> ask.
>>
>> 
>> 
>> Timothy Sipples
>> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
>> Multi-Geography
>> E-Mail: sipp...@sg.ibm.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
>

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

Re: VTL as 3490 vs 3590

[Tony Thigpen]

Timothy,

The biggest problem is that physical tape, unlike dasd, has been the 
primary method of data archive and data transport since it was created. 
(And that includes paper tape.) While tape virtualization is great for 
internal tapes, off-site archival now requires an expensive duplicate of 
the primary VTL. And, as machine age and are replaced, historical 
archival have to be converted to the new equipment.


Also, I could always point to the tape rack and tell the auditors: "You 
want the data from 20 years ago? There it is."


Tony Thigpen

Timothy Sipples wrote on 05/22/2018 02:04 AM:

Radoslaw Skorupka wrote:

It is really nice sales pitch, but *technically* IBM it is no longer
possible to write directly to a tape volume from z/OS.


First of all, it's not a sales pitch. I don't do sales pitches very well.

Second, it's also no longer possible to "write directly" to disk drives.
*All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
highly virtualized, with intelligent controllers equipped with caches.

Why is this progress a problem? And it's a very long arc of progress, not
at all sudden. As I've carefully and accurately documented, there was
nearly 19 years of product overlap as IBM tape made the transition to
virtualized-physical.

Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
attachment to your IBM TS7700. I have no inside information on that, but I
do pay some attention to IBM's past practices. What I see is that, for
several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the world's
most important financial records) and its long-term retention needs, but
ask.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.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

Re: VTL as 3490 vs 3590

[Edward Gould]

> On May 22, 2018, at 1:04 AM, Timothy Sipples  wrote:
> 
> Radoslaw Skorupka wrote:
>> It is really nice sales pitch, but *technically* IBM it is no longer
>> possible to write directly to a tape volume from z/OS.
> 
> First of all, it's not a sales pitch. I don't do sales pitches very well.
> 
> Second, it's also no longer possible to "write directly" to disk drives.
> *All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
> highly virtualized, with intelligent controllers equipped with caches.
> 
> Why is this progress a problem? And it's a very long arc of progress, not
> at all sudden. As I've carefully and accurately documented, there was
> nearly 19 years of product overlap as IBM tape made the transition to
> virtualized-physical.
> 
> Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
> attachment to your IBM TS7700. I have no inside information on that, but I
> do pay some attention to IBM's past practices. What I see is that, for
> several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the world's
> most important financial records) and its long-term retention needs, but
> ask.

Timothy,
I disagree about your sales pitches a little. You do do them but not as blatant 
as others.
I am wondering about your descriptions a little, from several perspectives IBM 
is cutting their head off. 
I have had about 5 times in my life as a sysprog, where various utilities 
*FROM* IBM absolutely needed a stand alone tape drive, i.e. one you had to 
mount a physical tape to do say a stand alone restore and the other function I 
needed was to supply the CE with a IOCP deck that was needed for a new system 
(fresh from IBM). There were others which I have done in mostly the middle of 
the night (one or two was with IBM[’s blessing).
I know its not an ever day occurrence but the point is you still need a 
physical tape drive.
I am attempting to remember other utility type functions that a physical tape 
was needed but it is late.
Ed


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

Re: VTL as 3490 vs 3590

[Timothy Sipples]

Radoslaw Skorupka wrote:
>It is really nice sales pitch, but *technically* IBM it is no longer
>possible to write directly to a tape volume from z/OS.

First of all, it's not a sales pitch. I don't do sales pitches very well.

Second, it's also no longer possible to "write directly" to disk drives.
*All* mainframe-attached storage -- flash/SSD, disk, and now tape -- is
highly virtualized, with intelligent controllers equipped with caches.

Why is this progress a problem? And it's a very long arc of progress, not
at all sudden. As I've carefully and accurately documented, there was
nearly 19 years of product overlap as IBM tape made the transition to
virtualized-physical.

Finally, "ask your friendly IBM representative" about IBM TS1155/TS4500
attachment to your IBM TS7700. I have no inside information on that, but I
do pay some attention to IBM's past practices. What I see is that, for
several generations of tape drives stretching back many years, 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 with your most precious data (such as most of the world's
most important financial records) and its long-term retention needs, but
ask.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: VTL as 3490 vs 3590

[R.S.]

W dniu 2018-05-21 o 11:19, Timothy Sipples pisze:

Radoslaw Skorupka wrote:

BTW2: It's big pity IBM stopped providing real tape drives for z/OS.

That would be a pity if it were true. Fortunately, it's not true. Tape
libraries, tape drives, and tape cartridges for z/OS (and for z/VSE, z/VM,
and z/TPF) are all available and popular.

IBM has stopped producing the lower performance "dumb" tape controllers
that topped out at 4Gb/s FICON links and that had no staging/caching
storage capabilities. IBM is focusing on the "smart" tape controller,
a.k.a. VTS, available with physical tape libraries, tape drives, and tape
cartridges that are better and faster than ever. That's progress, and
that's a good thing.

The IBM 3494-B16, the first generation smart controller, was generally
available on June 27, 1997 -- nearly 21 years ago. The last "dumb"
controller, the IBM 3592-C07, was withdrawn from marketing in most (all?)
countries on June 17, 2016. IBM maintenance services for the 3592-C07
controller will be available for some time to come (no End of Service date
announced).


Timothy,
It is really nice sales pitch, but *technically* IBM it is no longer 
possible to write directly to a tape volume from z/OS.
Yes, 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.


BTW: that's one of the reasons why IBM stopped software distribution on 
tapes. You cannot install software from TS1150 drive, even if attached 
via VTS.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Timothy Sipples]

Radoslaw Skorupka wrote:
>BTW2: It's big pity IBM stopped providing real tape drives for z/OS.

That would be a pity if it were true. Fortunately, it's not true. Tape
libraries, tape drives, and tape cartridges for z/OS (and for z/VSE, z/VM,
and z/TPF) are all available and popular.

IBM has stopped producing the lower performance "dumb" tape controllers
that topped out at 4Gb/s FICON links and that had no staging/caching
storage capabilities. IBM is focusing on the "smart" tape controller,
a.k.a. VTS, available with physical tape libraries, tape drives, and tape
cartridges that are better and faster than ever. That's progress, and
that's a good thing.

The IBM 3494-B16, the first generation smart controller, was generally
available on June 27, 1997 -- nearly 21 years ago. The last "dumb"
controller, the IBM 3592-C07, was withdrawn from marketing in most (all?)
countries on June 17, 2016. IBM maintenance services for the 3592-C07
controller will be available for some time to come (no End of Service date
announced).


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: VTL as 3490 vs 3590

[Brian Fraser]

Smaller volumes increase the chance that a volume will become totally
empty, rather than just drop below the recycle threshold.
Therefore eliminating the need to move data during recycle.

On Sun, May 20, 2018 at 4:48 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Actually I think you have that reversed, the smaller volumes will tend to
> increase the amount of recycling because less data has to be freed up to
> make a larger percentage of the volume and you have a LOT more of them.
> Although I have heard that some sites the use small volumes only free them
> at recycle when they are completely empty.
>
> Things can get even more complicated if you duplex the tapes.
>
> Brian
>
> --
> 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

Re: VTL as 3490 vs 3590

[Ken Bloom]

Tony

I believe that the volume size is stored in the TTOC and that you specify the % 
fill of the tape before it requests another volume.  So if you want to keep 
your volumes the size of a 3490 or 3590 you define it in HSM.  The HSM knows 
how much has been stored on the volume and when it reaches 97% (default value) 
it will mount another tape.  The Visara VTL does not care what type you define 
it as it will just write the volume as large as you want.   As a side note, for 
flexibility we do have a configuration to limit the size of the volume for 
those that want to limit the volume size. The amount of disk storage that is 
used by the volume is the size of the dataset(s) written.  I believe that we 
only have 1 customer that limits the vol size. 

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 20, 2018, at 7:37 AM, Tony Thigpen <t...@vse2pdf.com> wrote:
> 
> Ken,
> 
> So, how would you define volumes used by HSM so that they 'fill up' at some 
> point and new volumes are used?
> 
> Tony Thigpen
> 
> Ken Bloom wrote on 05/20/2018 01:43 AM:
>> If you mount volser A1 and write 500GB that's fine,  1 TB is also fine 
>> or however much data you want.  If it's 10 bytes that's fine too. The .AWS 
>> file representing the tape will be what ever size is written to it.  It can 
>> be a single data set or stacked sets.  We have very few customers that stack 
>> data sets on a tape because it's not necessary as there is no file size 
>> limit.  Granted searching a vtl volume is faster than a real tape, but 
>> having one data set to a tape does not expand the footprint of your tapes as 
>> everything fits on the same small disk drive footprint.  If you need a 
>> dataset mount the tape that has it, no need to search.
>> 
>> Ken
>> 
>> Kenneth A. Bloom
>> CEO
>> Avenir Technologies Inc
>> /d/b/a Visara International
>> 203-984-2235
>> bl...@visara.com
>> www.visara.com
>> 
>> 
>>> On May 20, 2018, at 12:29 AM, R.S. <r.skoru...@bremultibank.com.pl> wrote:
>>> 
>>> Ken,
>>> What does it mean you don't limit the size of the volume?
>>> I understand a job can write as much as it need to a single volume, that's 
>>> fine.
>>> However tools like DFSMSHSM tend to fill the volume up. In that case some 
>>> limit has to be used, otherwise the volume wiil grow up indefinitely.
>>> How do you address this issue?
>>> 
>>> Regards
>>> --
>>> Radoslaw Skorupka
>>> Lodz, Poland
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> W dniu 2018-05-18 o 20:05, Ken Bloom pisze:
>>>> Hi Russell
>>>> 
>>>> We don't limit the size of the VTL volume so size doesn't enter into it.
>>>> 
>>>> Regards
>>>> Ken
>>>> 
>>>> Kenneth A. Bloom
>>>> CEO
>>>> Avenir Technologies Inc
>>>> /d/b/a Visara International
>>>> 203-984-2235
>>>> bl...@visara.com
>>>> www.visara.com
>>>> 
>>>> 
>>>>> On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:
>>>>> 
>>>>> Tony,
>>>>> 
>>>>> 
>>>>> Another item to throw into the mix is what size of virtual-volumes you 
>>>>> define them as. With 3490's, you can define the virtual-volumes in 
>>>>> Gigabytes of capacity. If you stack lots of very small files, you run 
>>>>> into a problem with the Block-ID not being large enough. With them 
>>>>> defined as 3590's, the block-id issue is non-existent because the 
>>>>> Block-ID is a 4-byte field on the 3590's. So, if you like to define your 
>>>>> virtual-volumes as large volumes; it might actually be better to define 
>>>>> them as 3590's.
>>>>> 
>>>>> 
>>>>> Russell Witt
>>>>> res09...@verizon.net
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -Original Message-
>>>>> From: Tony Thigpen <t...@vse2pdf.com>
>>>>> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
>>>>> Sent: Fri, May 18, 2018 12:52 pm
>>>>> Subject: VTL as 3490 vs 3590
>>>>> 
>>>>> For a little fun on Friday afternoon.
>>>>> 
>>>>> We will be replacing our current VTL.
>>>>> 
>>>>>

Re: VTL as 3490 vs 3590

[Tony Thigpen]

Ken,

So, how would you define volumes used by HSM so that they 'fill up' at 
some point and new volumes are used?


Tony Thigpen

Ken Bloom wrote on 05/20/2018 01:43 AM:

If you mount volser A1 and write 500GB that's fine,  1 TB is also fine or 
however much data you want.  If it's 10 bytes that's fine too. The .AWS file 
representing the tape will be what ever size is written to it.  It can be a 
single data set or stacked sets.  We have very few customers that stack data 
sets on a tape because it's not necessary as there is no file size limit.  
Granted searching a vtl volume is faster than a real tape, but having one data 
set to a tape does not expand the footprint of your tapes as everything fits on 
the same small disk drive footprint.  If you need a dataset mount the tape that 
has it, no need to search.

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com



On May 20, 2018, at 12:29 AM, R.S. <r.skoru...@bremultibank.com.pl> wrote:

Ken,
What does it mean you don't limit the size of the volume?
I understand a job can write as much as it need to a single volume, that's fine.
However tools like DFSMSHSM tend to fill the volume up. In that case some limit 
has to be used, otherwise the volume wiil grow up indefinitely.
How do you address this issue?

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-05-18 o 20:05, Ken Bloom pisze:

Hi Russell

We don't limit the size of the VTL volume so size doesn't enter into it.

Regards
Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com



On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:

Tony,


Another item to throw into the mix is what size of virtual-volumes you define 
them as. With 3490's, you can define the virtual-volumes in Gigabytes of 
capacity. If you stack lots of very small files, you run into a problem with 
the Block-ID not being large enough. With them defined as 3590's, the block-id 
issue is non-existent because the Block-ID is a 4-byte field on the 3590's. So, 
if you like to define your virtual-volumes as large volumes; it might actually 
be better to define them as 3590's.


Russell Witt
res09...@verizon.net




-Original Message-
From: Tony Thigpen <t...@vse2pdf.com>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Fri, May 18, 2018 12:52 pm
Subject: VTL as 3490 vs 3590

For a little fun on Friday afternoon.

We will be replacing our current VTL.

The new VTL can be configured to look like 3490s or 3590s. Our current
VTL is defined to z/OS as 3490s.

Some of the staff are saying: "All VTLs should be defined as 3490s
because that is what everybody does."

Others are saying: "Let's make them 3590s because then they match the
few remaining physical 3590s and if we have an issue with the VTL we can
just swap the fiber and continue running on real 3590s until the problem
is fixed."

It was suggested I ask here to see what others are doing.

Thoughts?

--
Tony Thigpen




==


   --
TreœÌ tej wiadomoœci mo¿e zawieraÌ informacje prawnie chronione Banku 
przeznaczone wy³¹cznie do u¿ytku s³u¿bowego adresata. Odbiorc¹ mo¿e byÌ 
jedynie jej adresat z wy³¹czeniem dostêpu osób trzecich. Je¿eli nie 
jesteÂś adresatem niniejszej wiadomoÂści lub pracownikiem upowaÂżnionym do jej 
przekazania adresatowi, informujemy, Âże jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne dziaÂłanie o podobnym charakterze jest prawnie 
zabronione i mo¿e byÌ karalne. Je¿eli otrzyma³eœ tê wiadomoœÌ 
omyÂłkowo, prosimy niezwÂłocznie zawiadomiĂŚ nadawcĂŞ wysyÂłajÂąc odpowiedÂź 
oraz trwale usun¹Ì tê wiadomoœÌ w³¹czaj¹c 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 authorized 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.

mBank S.A. z siedzibÂą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsÂąd Rejonowy dla m. st. Warszawy XII 
WydziaÂł Gospodarczy Krajowego Rejestru SÂądowego, nr rejestru 
przedsiĂŞbiorcĂłw KRS 025237, NIP: 526-021-50-88. WedÂług stanu na dzieĂą 
01.01.2018 r. kapitaÂł zakÂładowy mBanku S.A. (w caÂło

Re: VTL as 3490 vs 3590

[Gibney, Dave]

FWIW, we are currently defined as 3590, PARTIALTAPE=MARKFULL and recycle 
percentage at 35%
We use FDRABR for DR volume/incremental backups and DFHSM for application 
dataset backup and migration. I am not aware of any multi-volume tape datasets. 
But, since I also haven't cared to look for such lately, I won’t say the none 
exist.

My point was that DFHSM, CA-1 are managing a fairly large count of tapes with 
no apparent problems.

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
> Behalf Of R.S.
> Sent: Saturday, May 19, 2018 11:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTL as 3490 vs 3590
> 
> OK, but what about program tending to fill the volume up?
> It's not matter of few hundreds terabytes, because it can be many terabytes
> - we talk about TS1140 (~12TB after compression) or T1D
> (21 TB)  per cart. Of course the tool (HSM or other) is able to fill up even
> larger volumes.
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2018-05-20 o 07:43, Ken Bloom pisze:
> > If you mount volser A1 and write 500GB that's fine,  1 TB is also fine 
> > or
> however much data you want.  If it's 10 bytes that's fine too. The .AWS file
> representing the tape will be what ever size is written to it.  It can be a 
> single
> data set or stacked sets.  We have very few customers that stack data sets on
> a tape because it's not necessary as there is no file size limit.  Granted
> searching a vtl volume is faster than a real tape, but having one data set to 
> a
> tape does not expand the footprint of your tapes as everything fits on the
> same small disk drive footprint.  If you need a dataset mount the tape that
> has it, no need to search.
> >
> > Ken
> >
> > Kenneth A. Bloom
> > CEO
> > Avenir Technologies Inc
> > /d/b/a Visara International
> > 203-984-2235
> > bl...@visara.com
> > www.visara.com
> >
> >
> >> On May 20, 2018, at 12:29 AM, R.S.
> <r.skoru...@bremultibank.com.pl> wrote:
> >>
> >> Ken,
> >> What does it mean you don't limit the size of the volume?
> >> I understand a job can write as much as it need to a single volume, that's
> fine.
> >> However tools like DFSMSHSM tend to fill the volume up. In that case
> some limit has to be used, otherwise the volume wiil grow up indefinitely.
> >> How do you address this issue?
> >>
> >> Regards
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 2018-05-18 o 20:05, Ken Bloom pisze:
> >>> Hi Russell
> >>>
> >>> We don't limit the size of the VTL volume so size doesn't enter into it.
> >>>
> >>> Regards
> >>> Ken
> >>>
> >>> Kenneth A. Bloom
> >>> CEO
> >>> Avenir Technologies Inc
> >>> /d/b/a Visara International
> >>> 203-984-2235
> >>> bl...@visara.com
> >>> www.visara.com
> >>>
> >>>
> >>>> On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net>
> wrote:
> >>>>
> >>>> Tony,
> >>>>
> >>>>
> >>>> Another item to throw into the mix is what size of virtual-volumes you
> define them as. With 3490's, you can define the virtual-volumes in Gigabytes
> of capacity. If you stack lots of very small files, you run into a problem 
> with
> the Block-ID not being large enough. With them defined as 3590's, the block-
> id issue is non-existent because the Block-ID is a 4-byte field on the 3590's.
> So, if you like to define your virtual-volumes as large volumes; it might
> actually be better to define them as 3590's.
> >>>>
> >>>>
> >>>> Russell Witt
> >>>> res09...@verizon.net
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -Original Message-
> >>>> From: Tony Thigpen <t...@vse2pdf.com>
> >>>> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
> >>>> Sent: Fri, May 18, 2018 12:52 pm
> >>>> Subject: VTL as 3490 vs 3590
> >>>>
> >>>> For a little fun on Friday afternoon.
> >>>>
> >>>> We will be replacing our current VTL.
> >>>>
> >>>> The new VTL can be configured to look like 3490s or 3590s. Our current
> >>>> VTL is defined to z/OS as 3490s.

Re: VTL as 3490 vs 3590

[Brian Westerman]

Actually I think you have that reversed, the smaller volumes will tend to 
increase the amount of recycling because less data has to be freed up to make a 
larger percentage of the volume and you have a LOT more of them.  Although I 
have heard that some sites the use small volumes only free them at recycle when 
they are completely empty.

Things can get even more complicated if you duplex the tapes.

Brian

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

Re: VTL as 3490 vs 3590

[Brian Fraser]

Even for HSM, that does fill up volumes. Smaller volume sizes are better as
it reduces the amount of recycling that needs to occur as the volumes
become fragmented.

On Sun, May 20, 2018 at 2:00 PM, R.S. <r.skoru...@bremultibank.com.pl>
wrote:

> OK, but what about program tending to fill the volume up?
> It's not matter of few hundreds terabytes, because it can be many
> terabytes - we talk about TS1140 (~12TB after compression) or T1D  (21
> TB)  per cart. Of course the tool (HSM or other) is able to fill up even
> larger volumes.
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 2018-05-20 o 07:43, Ken Bloom pisze:
>
> If you mount volser A1 and write 500GB that's fine,  1 TB is also fine
>> or however much data you want.  If it's 10 bytes that's fine too. The .AWS
>> file representing the tape will be what ever size is written to it.  It can
>> be a single data set or stacked sets.  We have very few customers that
>> stack data sets on a tape because it's not necessary as there is no file
>> size limit.  Granted searching a vtl volume is faster than a real tape, but
>> having one data set to a tape does not expand the footprint of your tapes
>> as everything fits on the same small disk drive footprint.  If you need a
>> dataset mount the tape that has it, no need to search.
>>
>> Ken
>>
>> Kenneth A. Bloom
>> CEO
>> Avenir Technologies Inc
>> /d/b/a Visara International
>> 203-984-2235
>> bl...@visara.com
>> www.visara.com
>>
>>
>> On May 20, 2018, at 12:29 AM, R.S. <r.skoru...@bremultibank.com.pl>
>>> wrote:
>>>
>>> Ken,
>>> What does it mean you don't limit the size of the volume?
>>> I understand a job can write as much as it need to a single volume,
>>> that's fine.
>>> However tools like DFSMSHSM tend to fill the volume up. In that case
>>> some limit has to be used, otherwise the volume wiil grow up indefinitely.
>>> How do you address this issue?
>>>
>>> Regards
>>> --
>>> Radoslaw Skorupka
>>> Lodz, Poland
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> W dniu 2018-05-18 o 20:05, Ken Bloom pisze:
>>>
>>>> Hi Russell
>>>>
>>>> We don't limit the size of the VTL volume so size doesn't enter into it.
>>>>
>>>> Regards
>>>> Ken
>>>>
>>>> Kenneth A. Bloom
>>>> CEO
>>>> Avenir Technologies Inc
>>>> /d/b/a Visara International
>>>> 203-984-2235
>>>> bl...@visara.com
>>>> www.visara.com
>>>>
>>>>
>>>> On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:
>>>>>
>>>>> Tony,
>>>>>
>>>>>
>>>>> Another item to throw into the mix is what size of virtual-volumes you
>>>>> define them as. With 3490's, you can define the virtual-volumes in
>>>>> Gigabytes of capacity. If you stack lots of very small files, you run into
>>>>> a problem with the Block-ID not being large enough. With them defined as
>>>>> 3590's, the block-id issue is non-existent because the Block-ID is a 
>>>>> 4-byte
>>>>> field on the 3590's. So, if you like to define your virtual-volumes as
>>>>> large volumes; it might actually be better to define them as 3590's.
>>>>>
>>>>>
>>>>> Russell Witt
>>>>> res09...@verizon.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: Tony Thigpen <t...@vse2pdf.com>
>>>>> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
>>>>> Sent: Fri, May 18, 2018 12:52 pm
>>>>> Subject: VTL as 3490 vs 3590
>>>>>
>>>>> For a little fun on Friday afternoon.
>>>>>
>>>>> We will be replacing our current VTL.
>>>>>
>>>>> The new VTL can be configured to look like 3490s or 3590s. Our current
>>>>> VTL is defined to z/OS as 3490s.
>>>>>
>>>>> Some of the staff are saying: "All VTLs should be defined as 3490s
>>>>> because that is what everybody does."
>>>>>
>>>>> Others are saying: "Let's make them 3590s because then they match the
>>>>> few remaining physical 3590s and if we have an issu

Re: VTL as 3490 vs 3590

[R.S.]

OK, but what about program tending to fill the volume up?
It's not matter of few hundreds terabytes, because it can be many 
terabytes - we talk about TS1140 (~12TB after compression) or T1D  
(21 TB)  per cart. Of course the tool (HSM or other) is able to fill up 
even larger volumes.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-05-20 o 07:43, Ken Bloom pisze:

If you mount volser A1 and write 500GB that's fine,  1 TB is also fine or 
however much data you want.  If it's 10 bytes that's fine too. The .AWS file 
representing the tape will be what ever size is written to it.  It can be a 
single data set or stacked sets.  We have very few customers that stack data 
sets on a tape because it's not necessary as there is no file size limit.  
Granted searching a vtl volume is faster than a real tape, but having one data 
set to a tape does not expand the footprint of your tapes as everything fits on 
the same small disk drive footprint.  If you need a dataset mount the tape that 
has it, no need to search.

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com



On May 20, 2018, at 12:29 AM, R.S. <r.skoru...@bremultibank.com.pl> wrote:

Ken,
What does it mean you don't limit the size of the volume?
I understand a job can write as much as it need to a single volume, that's fine.
However tools like DFSMSHSM tend to fill the volume up. In that case some limit 
has to be used, otherwise the volume wiil grow up indefinitely.
How do you address this issue?

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-05-18 o 20:05, Ken Bloom pisze:

Hi Russell

We don't limit the size of the VTL volume so size doesn't enter into it.

Regards
Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com



On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:

Tony,


Another item to throw into the mix is what size of virtual-volumes you define 
them as. With 3490's, you can define the virtual-volumes in Gigabytes of 
capacity. If you stack lots of very small files, you run into a problem with 
the Block-ID not being large enough. With them defined as 3590's, the block-id 
issue is non-existent because the Block-ID is a 4-byte field on the 3590's. So, 
if you like to define your virtual-volumes as large volumes; it might actually 
be better to define them as 3590's.


Russell Witt
res09...@verizon.net




-Original Message-
From: Tony Thigpen <t...@vse2pdf.com>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Fri, May 18, 2018 12:52 pm
Subject: VTL as 3490 vs 3590

For a little fun on Friday afternoon.

We will be replacing our current VTL.

The new VTL can be configured to look like 3490s or 3590s. Our current
VTL is defined to z/OS as 3490s.

Some of the staff are saying: "All VTLs should be defined as 3490s
because that is what everybody does."

Others are saying: "Let's make them 3590s because then they match the
few remaining physical 3590s and if we have an issue with the VTL we can
just swap the fiber and continue running on real 3590s until the problem
is fixed."

It was suggested I ask here to see what others are doing.

Thoughts?

--
Tony Thigpen






==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr r

Re: VTL as 3490 vs 3590

[Ken Bloom]

If you mount volser A1 and write 500GB that's fine,  1 TB is also fine or 
however much data you want.  If it's 10 bytes that's fine too. The .AWS file 
representing the tape will be what ever size is written to it.  It can be a 
single data set or stacked sets.  We have very few customers that stack data 
sets on a tape because it's not necessary as there is no file size limit.  
Granted searching a vtl volume is faster than a real tape, but having one data 
set to a tape does not expand the footprint of your tapes as everything fits on 
the same small disk drive footprint.  If you need a dataset mount the tape that 
has it, no need to search. 

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 20, 2018, at 12:29 AM, R.S. <r.skoru...@bremultibank.com.pl> wrote:
> 
> Ken,
> What does it mean you don't limit the size of the volume?
> I understand a job can write as much as it need to a single volume, that's 
> fine.
> However tools like DFSMSHSM tend to fill the volume up. In that case some 
> limit has to be used, otherwise the volume wiil grow up indefinitely.
> How do you address this issue?
> 
> Regards
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2018-05-18 o 20:05, Ken Bloom pisze:
>> Hi Russell
>> 
>> We don't limit the size of the VTL volume so size doesn't enter into it.
>> 
>> Regards
>> Ken
>> 
>> Kenneth A. Bloom
>> CEO
>> Avenir Technologies Inc
>> /d/b/a Visara International
>> 203-984-2235
>> bl...@visara.com
>> www.visara.com
>> 
>> 
>>> On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:
>>> 
>>> Tony,
>>> 
>>> 
>>> Another item to throw into the mix is what size of virtual-volumes you 
>>> define them as. With 3490's, you can define the virtual-volumes in 
>>> Gigabytes of capacity. If you stack lots of very small files, you run into 
>>> a problem with the Block-ID not being large enough. With them defined as 
>>> 3590's, the block-id issue is non-existent because the Block-ID is a 4-byte 
>>> field on the 3590's. So, if you like to define your virtual-volumes as 
>>> large volumes; it might actually be better to define them as 3590's.
>>> 
>>> 
>>> Russell Witt
>>> res09...@verizon.net
>>> 
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Tony Thigpen <t...@vse2pdf.com>
>>> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
>>> Sent: Fri, May 18, 2018 12:52 pm
>>> Subject: VTL as 3490 vs 3590
>>> 
>>> For a little fun on Friday afternoon.
>>> 
>>> We will be replacing our current VTL.
>>> 
>>> The new VTL can be configured to look like 3490s or 3590s. Our current
>>> VTL is defined to z/OS as 3490s.
>>> 
>>> Some of the staff are saying: "All VTLs should be defined as 3490s
>>> because that is what everybody does."
>>> 
>>> Others are saying: "Let's make them 3590s because then they match the
>>> few remaining physical 3590s and if we have an issue with the VTL we can
>>> just swap the fiber and continue running on real 3590s until the problem
>>> is fixed."
>>> 
>>> It was suggested I ask here to see what others are doing.
>>> 
>>> Thoughts?
>>> 
>>> -- 
>>> Tony Thigpen
>>> 
> 
> 
> ==
> 
> 
>   --
> TreœÌ tej wiadomoœci mo¿e zawieraÌ informacje prawnie chronione Banku 
> przeznaczone wy³¹cznie do u¿ytku s³u¿bowego adresata. Odbiorc¹ mo¿e 
> byÌ jedynie jej adresat z wy³¹czeniem dostêpu osób trzecich. Je¿eli nie 
> jesteÂś adresatem niniejszej wiadomoÂści lub pracownikiem upowaÂżnionym do 
> jej przekazania adresatowi, informujemy, Âże jej rozpowszechnianie, 
> kopiowanie, rozprowadzanie lub inne dziaÂłanie o podobnym charakterze jest 
> prawnie zabronione i mo¿e byÌ karalne. Je¿eli otrzyma³eœ tê wiadomoœÌ 
> omyÂłkowo, prosimy niezwÂłocznie zawiadomiĂŚ nadawcĂŞ wysyÂłajÂąc odpowiedÂź 
> oraz trwale usun¹Ì tê wiadomoœÌ w³¹czaj¹c 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 addresse

Re: VTL as 3490 vs 3590

[R.S.]

Ken,
What does it mean you don't limit the size of the volume?
I understand a job can write as much as it need to a single volume, 
that's fine.
However tools like DFSMSHSM tend to fill the volume up. In that case 
some limit has to be used, otherwise the volume wiil grow up indefinitely.

How do you address this issue?

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-05-18 o 20:05, Ken Bloom pisze:

Hi Russell

We don't limit the size of the VTL volume so size doesn't enter into it.

Regards
Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com



On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:

Tony,


Another item to throw into the mix is what size of virtual-volumes you define 
them as. With 3490's, you can define the virtual-volumes in Gigabytes of 
capacity. If you stack lots of very small files, you run into a problem with 
the Block-ID not being large enough. With them defined as 3590's, the block-id 
issue is non-existent because the Block-ID is a 4-byte field on the 3590's. So, 
if you like to define your virtual-volumes as large volumes; it might actually 
be better to define them as 3590's.


Russell Witt
res09...@verizon.net




-Original Message-
From: Tony Thigpen <t...@vse2pdf.com>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Fri, May 18, 2018 12:52 pm
Subject: VTL as 3490 vs 3590

For a little fun on Friday afternoon.

We will be replacing our current VTL.

The new VTL can be configured to look like 3490s or 3590s. Our current
VTL is defined to z/OS as 3490s.

Some of the staff are saying: "All VTLs should be defined as 3490s
because that is what everybody does."

Others are saying: "Let's make them 3590s because then they match the
few remaining physical 3590s and if we have an issue with the VTL we can
just swap the fiber and continue running on real 3590s until the problem
is fixed."

It was suggested I ask here to see what others are doing.

Thoughts?

--
Tony Thigpen




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[R.S.]

From the other hand - what's wrong in defining 3590 emulation? Does it 
hurt?


I know what's wrong with plenty of small volumes: problems.
Problems with DFSMSHSM limitations (recently relieved, but not to much), 
problems with multi-volume TAPEVOL profile size, possible VTS capacity 
limitations, etc.
I see no advantage with having a lot of small volumes (note the we talk 
about max size, not actual size of given volume).


BTW: Few years ago when I was implementing T1 drives in z/OS 
environment, the only possible emulation was 3590 (actually 3292, which 
is defined to HCD as 3590, but DS provide further details). The reason 
for that was explained by huge capacity of the drive which causes block 
id space to exhaust.

Of course it is real tape drive.

BTW2: It's big pity IBM stopped providing real tape drives for z/OS.

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-05-19 o 19:18, Gibney, Dave pisze:

Why is it a pain to write "lots"  of virtual tapes. I turned all stacking off 
and defined x1-9 in my tape pools when we moved away from cartridges. Never looked 
back


-Original Message-
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Brian Westerman
Sent: Saturday, May 19, 2018 2:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTL as 3490 vs 3590

3590's are "easier" to deal with if you use HSM at all, 3490's have to be set up
as a percentage of the 3490 capacity, (otherwise you get something like
800MB tapes (to HSM).   While the VTS could care less, it is a pain to have
HSM writing 600 tapes a day.

Several sites (about 1/3) we support are using VTL's as 3490's but most are
defined as 3590's.  The actual numbers are (out of 117 sites with VTL's) 36 are
defined as 3490's although almost all of them use a larger tape "size" (some
(most) are 2GB some or 5GB and a couple have no limit), whereas the rest of
them (81 sites) are defined as 3590's.

Speed-wise, I don't think there is a difference, at least not that I can tell.

Different VTL vendors seem to use different compression techniques so the
sizes vary as to how much actually fits on a tape dataset after compression
before it wants to load the next tape.

I don't agree (but no one cares) with the sites that don't specify a limit to 
the
tape size.  I think that's just asking for a problem somewhere down the line,
but if that's what the client wants, we will run that way.

If left to my own preferences, I would choose 3590 every time.  I also like
those VTL's that don't keep the tape/disk storage inside the device and use
NetApp or something similar or like EMC does where the DASD is logically
pretty separate.  Again, that's just a personal preference thing.

Brian





==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: VTL as 3490 vs 3590

[Ken Bloom]

Dave

Completely agree!

Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 19, 2018, at 1:18 PM, Gibney, Dave <gib...@wsu.edu> wrote:
> 
> Why is it a pain to write "lots"  of virtual tapes. I turned all stacking off 
> and defined x1-9 in my tape pools when we moved away from cartridges. 
> Never looked back
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
>> Behalf Of Brian Westerman
>> Sent: Saturday, May 19, 2018 2:52 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: VTL as 3490 vs 3590
>> 
>> 3590's are "easier" to deal with if you use HSM at all, 3490's have to be 
>> set up
>> as a percentage of the 3490 capacity, (otherwise you get something like
>> 800MB tapes (to HSM).   While the VTS could care less, it is a pain to have
>> HSM writing 600 tapes a day.
>> 
>> Several sites (about 1/3) we support are using VTL's as 3490's but most are
>> defined as 3590's.  The actual numbers are (out of 117 sites with VTL's) 36 
>> are
>> defined as 3490's although almost all of them use a larger tape "size" (some
>> (most) are 2GB some or 5GB and a couple have no limit), whereas the rest of
>> them (81 sites) are defined as 3590's.
>> 
>> Speed-wise, I don't think there is a difference, at least not that I can 
>> tell.
>> 
>> Different VTL vendors seem to use different compression techniques so the
>> sizes vary as to how much actually fits on a tape dataset after compression
>> before it wants to load the next tape.
>> 
>> I don't agree (but no one cares) with the sites that don't specify a limit 
>> to the
>> tape size.  I think that's just asking for a problem somewhere down the line,
>> but if that's what the client wants, we will run that way.
>> 
>> If left to my own preferences, I would choose 3590 every time.  I also like
>> those VTL's that don't keep the tape/disk storage inside the device and use
>> NetApp or something similar or like EMC does where the DASD is logically
>> pretty separate.  Again, that's just a personal preference thing.
>> 
>> Brian
>> 
>> --
>> 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

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

Re: VTL as 3490 vs 3590

[Gibney, Dave]

Why is it a pain to write "lots"  of virtual tapes. I turned all stacking off 
and defined x1-9 in my tape pools when we moved away from cartridges. Never 
looked back

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
> Behalf Of Brian Westerman
> Sent: Saturday, May 19, 2018 2:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTL as 3490 vs 3590
> 
> 3590's are "easier" to deal with if you use HSM at all, 3490's have to be set 
> up
> as a percentage of the 3490 capacity, (otherwise you get something like
> 800MB tapes (to HSM).   While the VTS could care less, it is a pain to have
> HSM writing 600 tapes a day.
> 
> Several sites (about 1/3) we support are using VTL's as 3490's but most are
> defined as 3590's.  The actual numbers are (out of 117 sites with VTL's) 36 
> are
> defined as 3490's although almost all of them use a larger tape "size" (some
> (most) are 2GB some or 5GB and a couple have no limit), whereas the rest of
> them (81 sites) are defined as 3590's.
> 
> Speed-wise, I don't think there is a difference, at least not that I can tell.
> 
> Different VTL vendors seem to use different compression techniques so the
> sizes vary as to how much actually fits on a tape dataset after compression
> before it wants to load the next tape.
> 
> I don't agree (but no one cares) with the sites that don't specify a limit to 
> the
> tape size.  I think that's just asking for a problem somewhere down the line,
> but if that's what the client wants, we will run that way.
> 
> If left to my own preferences, I would choose 3590 every time.  I also like
> those VTL's that don't keep the tape/disk storage inside the device and use
> NetApp or something similar or like EMC does where the DASD is logically
> pretty separate.  Again, that's just a personal preference thing.
> 
> Brian
> 
> --
> 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

Re: VTL as 3490 vs 3590

[Brian Westerman]

3590's are "easier" to deal with if you use HSM at all, 3490's have to be set 
up as a percentage of the 3490 capacity, (otherwise you get something like 
800MB tapes (to HSM).   While the VTS could care less, it is a pain to have HSM 
writing 600 tapes a day.

Several sites (about 1/3) we support are using VTL's as 3490's but most are 
defined as 3590's.  The actual numbers are (out of 117 sites with VTL's) 36 are 
defined as 3490's although almost all of them use a larger tape "size" (some 
(most) are 2GB some or 5GB and a couple have no limit), whereas the rest of 
them (81 sites) are defined as 3590's.  

Speed-wise, I don't think there is a difference, at least not that I can tell.  

Different VTL vendors seem to use different compression techniques so the sizes 
vary as to how much actually fits on a tape dataset after compression before it 
wants to load the next tape.  

I don't agree (but no one cares) with the sites that don't specify a limit to 
the tape size.  I think that's just asking for a problem somewhere down the 
line, but if that's what the client wants, we will run that way.

If left to my own preferences, I would choose 3590 every time.  I also like 
those VTL's that don't keep the tape/disk storage inside the device and use 
NetApp or something similar or like EMC does where the DASD is logically pretty 
separate.  Again, that's just a personal preference thing.

Brian

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

Re: VTL as 3490 vs 3590

[John McKown]

On Fri, May 18, 2018 at 12:52 PM Tony Thigpen  wrote:

> For a little fun on Friday afternoon.
>
> We will be replacing our current VTL.
>
> The new VTL can be configured to look like 3490s or 3590s. Our current
> VTL is defined to z/OS as 3490s.
>
> Some of the staff are saying: "All VTLs should be defined as 3490s
> because that is what everybody does."
>
> Others are saying: "Let's make them 3590s because then they match the
> few remaining physical 3590s and if we have an issue with the VTL we can
> just swap the fiber and continue running on real 3590s until the problem
> is fixed."
>
> It was suggested I ask here to see what others are doing.
>

​We don't have that option here, we're stuck with 3490s. What I would
consider is the average size of the data sets put on a virtual tape. ​And I
don't know which VTL you are looking at, so I don't know how it works. My
first thought is if you have a lot of multi-volume 3490 virtuals, it might
be better to use 3590 as a base so that there are few virtual tapes changed
together. The plus of this is easier tape management. The minus is that if
the entire contents of a virtual tape need to be somehow "stage" onto a
cache disk (like on our 3494-B10), then there is the "problem" of staging a
singe 3590's contents into the cache; which will take longer than staging
the contents of multiple 3490 virtual tapes on an "as needed" basis. Also
the entire 3590 must remain cached until it is completely processed (or the
job abends) whereas with multiple 3490s, when the job finishes with one
3490, the cache for that volume can be put on the release list and reused.
This could be a serious consideration depending on cache size. Again,
assuming that the VTL uses some sort of intermediate cache. Hum, I guess I
arguing for 3490s based on: (1) reduced use of cache; (2) faster start to
the job since less data needs to be copied into the cache. But if the VTL
keeps all of the virtual tape data on disk and simply emulates tape access
onto a disk file (no intermediate cache), then I'd go with 3590.



>
> Thoughts?
>
> --
> Tony Thigpen
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

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

Re: VTL as 3490 vs 3590

[Ken Bloom]

Hi Russell

We don't limit the size of the VTL volume so size doesn't enter into it. 

Regards
Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 18, 2018, at 2:03 PM, Russell Witt <res09...@verizon.net> wrote:
> 
> Tony,
> 
> 
> Another item to throw into the mix is what size of virtual-volumes you define 
> them as. With 3490's, you can define the virtual-volumes in Gigabytes of 
> capacity. If you stack lots of very small files, you run into a problem with 
> the Block-ID not being large enough. With them defined as 3590's, the 
> block-id issue is non-existent because the Block-ID is a 4-byte field on the 
> 3590's. So, if you like to define your virtual-volumes as large volumes; it 
> might actually be better to define them as 3590's.
> 
> 
> Russell Witt
> res09...@verizon.net
> 
> 
> 
> 
> -Original Message-
> From: Tony Thigpen <t...@vse2pdf.com>
> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
> Sent: Fri, May 18, 2018 12:52 pm
> Subject: VTL as 3490 vs 3590
> 
> For a little fun on Friday afternoon.
> 
> We will be replacing our current VTL.
> 
> The new VTL can be configured to look like 3490s or 3590s. Our current 
> VTL is defined to z/OS as 3490s.
> 
> Some of the staff are saying: "All VTLs should be defined as 3490s 
> because that is what everybody does."
> 
> Others are saying: "Let's make them 3590s because then they match the 
> few remaining physical 3590s and if we have an issue with the VTL we can 
> just swap the fiber and continue running on real 3590s until the problem 
> is fixed."
> 
> It was suggested I ask here to see what others are doing.
> 
> Thoughts?
> 
> -- 
> Tony Thigpen
> 
> --
> 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

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

Re: VTL as 3490 vs 3590

[Russell Witt]

Tony,


Another item to throw into the mix is what size of virtual-volumes you define 
them as. With 3490's, you can define the virtual-volumes in Gigabytes of 
capacity. If you stack lots of very small files, you run into a problem with 
the Block-ID not being large enough. With them defined as 3590's, the block-id 
issue is non-existent because the Block-ID is a 4-byte field on the 3590's. So, 
if you like to define your virtual-volumes as large volumes; it might actually 
be better to define them as 3590's.


Russell Witt
res09...@verizon.net




-Original Message-
From: Tony Thigpen <t...@vse2pdf.com>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Fri, May 18, 2018 12:52 pm
Subject: VTL as 3490 vs 3590

For a little fun on Friday afternoon.

We will be replacing our current VTL.

The new VTL can be configured to look like 3490s or 3590s. Our current 
VTL is defined to z/OS as 3490s.

Some of the staff are saying: "All VTLs should be defined as 3490s 
because that is what everybody does."

Others are saying: "Let's make them 3590s because then they match the 
few remaining physical 3590s and if we have an issue with the VTL we can 
just swap the fiber and continue running on real 3590s until the problem 
is fixed."

It was suggested I ask here to see what others are doing.

Thoughts?

-- 
Tony Thigpen

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

Re: VTL as 3490 vs 3590

[Ken Bloom]

Hi Tony

Most of the time we define the drives on the Visara 5990A/L as 3490 and only 
define them as 3590 if the customer has a "desire" to define 3490. 

Bottom line is that it will not make a difference.  

Regards
Ken

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On May 18, 2018, at 1:52 PM, Tony Thigpen  wrote:
> 
> For a little fun on Friday afternoon.
> 
> We will be replacing our current VTL.
> 
> The new VTL can be configured to look like 3490s or 3590s. Our current VTL is 
> defined to z/OS as 3490s.
> 
> Some of the staff are saying: "All VTLs should be defined as 3490s because 
> that is what everybody does."
> 
> Others are saying: "Let's make them 3590s because then they match the few 
> remaining physical 3590s and if we have an issue with the VTL we can just 
> swap the fiber and continue running on real 3590s until the problem is fixed."
> 
> It was suggested I ask here to see what others are doing.
> 
> Thoughts?
> 
> -- 
> Tony Thigpen
> 
> --
> 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

VTL as 3490 vs 3590

[Tony Thigpen]

For a little fun on Friday afternoon.

We will be replacing our current VTL.

The new VTL can be configured to look like 3490s or 3590s. Our current 
VTL is defined to z/OS as 3490s.


Some of the staff are saying: "All VTLs should be defined as 3490s 
because that is what everybody does."


Others are saying: "Let's make them 3590s because then they match the 
few remaining physical 3590s and if we have an issue with the VTL we can 
just swap the fiber and continue running on real 3590s until the problem 
is fixed."


It was suggested I ask here to see what others are doing.

Thoughts?

--
Tony Thigpen

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