I suspected that you were with your brother. This must be quite
disheartening to say the least.
The man from CRA is back from holidays and asked yesterday how the MICS
component was coming along.
John T. Abell
President
International Software Products
Tel: 800-295-7608 Ext: 224
International: 1-416-593-5578 Ext: 224
Fax: 800-295-7609
International: 1-416-593-5579
E-mail: john.ab...@intnlsoftwareproducts.com
Web: www.ispinfo.com
This email may contain confidential and privileged material for the sole use
of the intended recipient(s). Any review, use, retention, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient),
please contact the sender by reply email and delete all copies of this
message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive
emails on the basis that we are not liable for any such corruption,
interception, tampering, amendment or viruses or any consequence thereof.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Tuesday, August 26, 2014 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: [IBM-MAIN] General question on moving DFHSM work
from mix TAPE/DASD to More DASD
Ron,
One of your explanation paragraphs caught my attention so I'm asking out of
curiosity, for my own benefit.
<your paragraph>
What I find important is there is no data transformation or recall latency:
it is all transparent to the application. You have to read 12 months of
General Ledger files or SMF data sets? The application simply reads them
directly from whatever tier disk the pages happen to be on. You're not
waiting 24 hours for data sets scattered all over myriad ML2 tapes to be
recalled, you don't have to find redundant Primary space to store the
recalled data sets, and there won't be any TMM thrash when they are migrated
again by the next space management cycle. That process is transparent to
z/OS in the way we thought the STK Iceberg would go. Of course all this
dormant data remains replicated with TC and/or HUR while it is being
shuffled around the backstore tiers in both sites - you're not moving any
DFSMShsm traffic across the replication links.
</your paragraph>
The sentence where you said "the application simply reads them directly from
whatever tier disk the pages happen to be on" intrigues me. Does the HDS
scenario you are talking about here use some kind of algorithm to leave this
kind of data on the level-3 spindles for a certain number of reads (or
something else like that) or once the page is referenced does it work in the
background to elevate the pages to higher performance tiers?
Thanks,
Rex
The information contained in this message is confidential, protected from
disclosure and may be legally privileged. If the reader of this message is
not the intended recipient or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any disclosure, distribution, copying, or any action taken or action
omitted in reliance on it, is strictly prohibited and may be unlawful. If
you have received this communication in error, please notify us immediately
by replying to this message and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
