On Wed, 17 Oct 2007 12:51:59 +0200, R.S. <[EMAIL PROTECTED]> wrote:
>In fact, I met STK outages, but not DASD outages. Modern DASD is fully
>redundant, CF outage - that's why we have spare CF. Sysplex is
>redundant, but usually single HSC CDS set serves multiple sysplexes. We
>don't have spare STK HSC(*). (although it is theoretically possible).
I think we are going in circles here. Following your argument... nothing
important (which SMF isn't really IMO... but no one likes to lose it) should
ever go directly to virtual tape. I haven't been convinced by any past
experience to think that way. In the environments that create a huge
amount of SMF data, virtual tape is a convenient and quick way to
manage it. If it was dumped to disk, it still would need to be copied
to tape in a subsequent step / job, so that would be extra processing
that just isn't needed. Even if there was enough DASD set aside to
put it all on disk for a 24 hour period, that would add processing
time at the end of the day to get it back to tape. Now multiply that
by 25 LPARs.
To your points above... the VSM hardware is just as fully redundant as
DASD (it *is* DASD). The SL8500 library is fully redundant (but even
problems with the back end physical drives don't keep the VSM from
creating new output tapes and reading in tapes from the buffer).
The HSC CDS is a single point of failure... but it is on all that modern
DASD and it also has a secondary backup copy (which should be kept
on a separate controller if available). There is even a 3rd ('standby')
CDS if you are so inclined to run that way.
>
> From my *very* limited experience: Usually HSC outages are really short.
As you said.. occasionally HSC/VTCS has hiccuped (STC abended),
but it gets restarted and all is good.
>
>I agree, DB2 logs are much much more important, than SMF. That's why I
>would suggest having archlogs on DASD and HSM (interval) migration to
>tape. Similar process for SMF and other "logs". Asynchronous processes.
>
Nothing wrong with that. Buf for us, some LPARs in some environments
don't even have HSM running - but have lots of DB2 (on our SAP LPARs
z/OS is really just a DB2 back end for SAP on AIX). HSM could be
implemented there (I wish it was)... but never has been by the
DASD Geeks (tm). Other environments never implemented HSM migration
duplexing for DR (in the past) - another problem in that scenario.
OTOH, we have fully duplexed all our virtual tape for DR since day 1 of
using VSM. DR was one of the main factors that led to getting rid of
VTS when we did that (many years ago now).
So fast forward 6 or 7 years to the present... and the landscape is
different and things could change, but since we've never had a reason
to change it.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
