Re: Splitting an DFSMShsm environment



Just brainstorming (usually I just take a couple of asprin when this
happens) - here's one method to consider:

Back up all your 'test' dsn's on ML1 & ML2 only using ABARS & then
restore on the test system to an empty newly created HSM environment to
the same migration level - which then leaves you the clean up of all your
test dsn's on production. I like this one as it leaves your production
environment in place

Or vice versa - backup the prod names, restore to the new production HSM,
and then clean up the test environment. With this method, your production
environment would be more likely to be pristine.

You could actually wait on the clean up, which would give you
recoverability if there were problems.

Either way, I think you'd have to turn migration off during the move or
run it in multiple phases to pick everything up. You might need to
inflate your storage groups to handle things during the split.

Are they talking about splitting tape pools, the tape management system,
SMS environments, hardware, etc? If so, I'd say you have plenty of job
security in the works.
ddkeller







"McKown, John" <John.Mckown@xxxxxxxxxxxxxxxxx>
Sent by: IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>
11/12/2007 11:50 AM
Please respond to
IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>


To
IBM-MAIN@xxxxxxxxxxx
cc

Subject
Splitting an DFSMShsm environment






I have been told that we WILL be splitting our single production z/OS
1.8 image in twain. The only reason I have been given that makes sense
is so that we will have a non-production, heavy use, image for testing
software upgrades. Currently we test software upgrades (z/OS and program
products) on a sysprog-only "sandbox" system.

We will do this splitting by creating a new LPAR on our current machine.
I am trying to convince everybody that we must go to a parallel sysplex
as "best". However, since this will require a CF LPAR (we have the
storage), we will need to acquire a CFL processor to run it. This means
a hard cash money. There is some "doubt" about the "cost effectiveness"
of this. So I may end up with a basic sysplex instead. There are even a
few people who want two separate monoplexes ( no sharing except with
"file transfer" volumes). One thing that I think is a big problem,
except in a parallel sysplex, is the fact that we have about 6Gig of
data either "backed up" or "migrated" with HSM. I don't know of any way
to "split" the HSM environment without a lot of contortions. Which
basically means that I would need to HRECALL everything that "belongs"
to the "new" z/OS image before attempting the split.

The question: Is there any way to split an MCS in two, based on DSN? If
so, what about the volumes on which the datasets reside? I ask because
HSM does not attempt to isolate data based on DSN or anything else that
I can determine. Is there a way to direct one set of HLQs to a "pool"
and all others to another "pool" of tape volumes?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


**************************************************************************************
This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof.

Thank you.
**************************************************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.



Relevant Pages

  • Re: DASD: to share or not to share
    ... I agree that capping a shared (Production) CF could be dangerous, and I have a hard time imagining a configuration where I would consider such a thing. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: about IEWL parameters or so
    ... I can replace the module from the production copy and try again. ... about IEWL parameters or so ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: Bringing the fun back to z/OS - new course
    ... environment where a cell group in support of an applicationcan consist ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: (CORRECTION) Assigning service class depending on system
    ... At my last shop, we did it to encourage TSO users to sign on to development, rather than production. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)
  • Re: CF Level Considerations at DR
    ... Don't exploit new function if your production CF is at a higher level than DR. ... but your DR CF does not, don't enable duplexing. ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)