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 T10000 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-99999 in my tape pools when we moved away from cartridges. Never looked 
back

-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On
Behalf Of Brian Westerman
Sent: Saturday, May 19, 2018 2:52 AM
To: [email protected]
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: [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

Reply via email to