An odd thing happened when I was looking at an application that
was burning CPU. Because they had gone to LBI (Large Block
Interface) and because we were using a VTS (don't know which
one), reads and buffer xfer were faster to C-Store (memory) than
DASD was!! Since they were also doing READ READ CHECK (a BSAM
thing that allows one to do work and not be waiting on I/O), they
had basically tuned out I/O waits!!.
IF you know your JOBs are using LBI, the following may not mean
anything to you:
I had offloaded enough of test DATA for that application to take
up 2 3390-3 volumes. And then I loaded that much to "tape" using
LBI. Our system read the same data from the "tape" faster than it
did the disk drives (back on z12 CECs).
If you haven't verified that their applications can handle LBI,
you might want to do this. You might cut down on the number of
tape volumes you have in your VTS as a result of going to LBI.
This may also tell you what "tape" data sets are your low hanging
fruit for getting back some of your resources.
While what I'm saying may seem to you to go opposite of what you
are trying to do, you may find this bit of info helps you deal
with both situations, too much data for DASD staging, and too
little data to be worth eating up tape.
HTHs,
Steve Thompson
On 1/31/19 3:30 PM, Benik, John E wrote:
Thank you for all the feedback. Even though we are all virtual tape, I am
under the impression that not all the data residing on tape should be. Yes
it's virtual and therefore disk, but many of the JCL used today is old and
since there is no chargeback for tape, users continue to write their data to
tape. I am looking into this to help determine where the data should reside.
The best will probably be looking at smaller tapes and having those go to disk
instead. I'm thinking starting with 50 MB.
John Benik | Optum
Senior Systems Management Analyst – Mainframe Storage, Network Hosting Services
Optum Technology
12125 Technology Drive
Eden Prairie, MN 55344
O) 1-952-833-7765
C) 1-612-616-3984
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, January 30, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tape Mount Mangement
On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:
My other impression is it's simpler to change gazillion (usually less)
of JCL jobs to explicitly point datasets to DASD than using TMM.
Might a JCLLIB member that SETs a few JCL symbols facilitate this?
Reduce a gazillion to a handful? Nowadays JCL symbols can even
be resolved in SYSIN.
Of course virtual tape reliefs many pains of tape, but keeping things in
old way is not good for the future.
IBM sometimes seems to have the opposite impression. "Compatibility".
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
----------------------------------------------------------------------
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
