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. <[email protected]> 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 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 > <https://maps.google.com/?q=se+advise+the+sender+immediately&entry=gmail&source=g> > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
