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 T10000D
(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 A00001 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
[email protected]
www.visara.com
On May 20, 2018, at 12:29 AM, R.S. <[email protected]> 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
[email protected]
www.visara.com
On May 18, 2018, at 2:03 PM, Russell Witt <[email protected]> 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
[email protected]
-----Original Message-----
From: Tony Thigpen <[email protected]>
To: IBM-MAIN <[email protected]>
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: [email protected]ąd Rejonowy dla m. st. Warszawy XII
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców
KRS 0000025237, 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 [email protected] with the message: INFO IBM-MAIN
