(repeat - I realized I sent this to newsgroup instead of to the list)
Of course you have to have backups!
We don't have one application but many; most with CICS, DB2, and batch
job stream components and many interrelated datasets and tables. Batch
job streams control the generation of consis
I don't know your application, but IMHO every application design should
include backup considerations. When I hear "24x7 and no time for
backups" I also hear (ashamed whisper) "in fact we do backups, but it
take whole week to finish it. Recovery would be horrible, we didn't
tested it yet". One
An interesting difference in philosophy. We use HSM less for backups
and more for space management. The backup capability sounded attractive
initially, but we quickly found that with some application batch running
almost 24x7 there were too many cases where the timing of autobackup
and/or the
ML2 datasets are guaranteed an HSM backup ONLY if they are defined with
an SMS management class that requires auto backup. Auto backups may not
be useful in many applications where the timing and synchronization of
backups must correspond to application processing cycles, not the whims
of DFhs
>DFHSM is a "band aid" we use because we
cannot force users to manage
their DASD usage.
>So, we migrate it from DASD to tape, then
eventually
delete it.
>This is a "political" fix. Other than that, I
agree that
keeping it DASD resident would be better.
I strongly disagree. Users should be insu
Hal Merritt wrote:
Forgive me guys, I don't get it. All HSM does is move data from cheap
DASD to expensive tape and back. I doubt it even does much compression
on modern DASD or tape. It just shuffles data around. Yes, HSM offers
some nice management features, but are they worth the price?
> Terry and Ron (don't you *ever* sleep ???) we have done what we can.
> Sometimes customers do as one recommends, sometimes not.
>
Or customers do what suits them...
Stephen Mednick
Computer Supervisory Services
Sydney, Australia
-
Terry and Ron (don't you *ever* sleep ???) we have done what we can.
Sometimes customers do as one recommends, sometimes not.
'nuff said.
Shane ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt
> Sent: Wednesday, January 11, 2006 1:45 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DFSMShsm & 3592 carts & money
>
>
> Forgive me guys, I
you.
My $0.02.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Traylor, Terry
Sent: Wednesday, January 11, 2006 10:13 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSMShsm & 3592 carts & money
Shane,
Consider implementing HSM Auxiliary Ad
John,
I just noticed this thread of messages regarding 3592s and DFHSM ML2 and
the thought of using OPENTECH TapeCopy to stack multiple ML2 tapes on one
3592.
===> Don't even think about that ! <===
Please do yourself a big favor and do _NOT_ touch ML2 tapes with TapeCopy.
ML2 tapes are recorded in
Shane,
It may not be the case for your customer, but when I find TMM environments
using lots of CPU, 9 times out of 10 they have compression on for tape
output, or they have a lot of TMM going to ML2 via ML1 instead of direct
from Primary to ML2.
Ron
>
> And for anyone interested, they are movi
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
>
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Chase, John
>
>
>
> >
> > With Windoze you don't need to waste time making backups. If
> > something goes
> > kab
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of ibm-main
Sent: Wednesday, January 11, 2006 12:56 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DFSMShsm & 3592 carts & money
From: "Gibney, Dave"
:Run it a single purpose z/OS.e
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John
> Sent: Wednesday, January 11, 2006 6:52 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DFSMShsm & 3592 carts & money
>
>
> With Windoze
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Russell Witt
> Sent: Tuesday, January 10, 2006 8:59 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DFSMShsm & 3592 carts & money
>
>
> Be careful using
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
>
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Hal Merritt
> >
> > Gee. Doesn't 'single point of failure' count for anything any more?
> > What happens when (not if
McKown, John wrote:
Nice subject?
Anyway does anybody else out there have 3592 drives? Are you using them
for DFSMShsm ML2 data? At present, we are debating putting HSM ML2 data
on 3592 carts. The other option is to use 3490E __virtual__ carts and
use OpenTECH's TapeCopy to stack the virtual car
ed all the old
stuff off the 3490's and the maintenance on them is getting to bother my
bosses a fair amount.
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of ibm-main
> Sent: Tuesday, January 10, 2006 11:56 PM
> To: IB
From: "Gibney, Dave"
:Run it a single purpose z/OS.e LPAR :) I wish I had this option.
:
:I run HSM on a fairly low priority class. When we're CPU tight I drop
: it even further.
:But, you are right, it runs all the time and recycle and tapecopy can
: take hours or even days. And our D
Hal Merritt wrote:
Gee. Doesn't 'single point of failure' count for anything any more? What
happens when (not if) one of those tape goes bad or gets destroyed?
That's one heckofa lot of data lost.
I guess that means one might want to have more than one copy. Two would
be better. Gee. This so
tical :(
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Shane Ginnane
> Sent: Tuesday, January 10, 2006 8:25 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DFSMShsm & 3592 carts & money
>
> Russell wrote on 11/
Russell wrote on 11/01/2006 12:58:42 PM:
> Of course there is also the 3494/VTS Duplex environment, where you have a
> 3494/VTS both onsite and offsite and they mirror each other (no need to
move
> cartridges at all).
We have a customer just venturing off TMM to a VTS solution, and they are
going
ent: Tuesday, January 10, 2006 3:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: DFSMShsm & 3592 carts & money
Nice subject?
Anyway does anybody else out there have 3592 drives? Are you using them
for DFSMShsm ML2 data? At present, we are debating putting HSM ML2 data
on 3592 carts. The other o
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt
> Sent: Tuesday, January 10, 2006 4:08 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DFSMShsm & 3592 carts & money
>
>
> Gee. Doesn&#x
solution is getting expensive.
Just a thought.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of McKown, John
Sent: Tuesday, January 10, 2006 3:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: DFSMShsm & 3592 carts & money
Nice subject?
Anyway
Nice subject?
Anyway does anybody else out there have 3592 drives? Are you using them
for DFSMShsm ML2 data? At present, we are debating putting HSM ML2 data
on 3592 carts. The other option is to use 3490E __virtual__ carts and
use OpenTECH's TapeCopy to stack the virtual carts onto physical 3592
27 matches
Mail list logo
