My customer tested this solution and will start using this solution in
production the weekend of 10 June. We too asked if the Linux server
couldn"t run under z/VM...
We will not use the PROP user they provide: a VMOPER action routine
directly issues the SMSG's to the "IP talking" service machine. It was
just too simple to not to use the extra PROP server.
Kris,
IBM Belgium, VM customer support
Mike Walter <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
2006-05-31 20:08
Please respond to
The IBM z/VM Operating System
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM for DB2 Backups
Odd... we're installing a Sun/STK VTS here, and we fully expect z/VM to
work with it. Getting it to work is lots more complex than installing
RMSMASTR and having VM:Tape work with IBM's VTS. (I used to think *that*
was hokey -- live and learn).
The Sun/STK solution is significantly (and needlessly) more convoluted.
We have not started the Sun/STK installation on the z/VM system yet (z/OS
needs it first, and will get it first), but my current understanding is
that it requires PROP (or VM:Operator) action routines, a CMS service
machine that talks "IP" to a Linux server. The Linux box will talk over
IP to a started task on a z/OS system. The z/OS system started task
application talks directly to the Sun/STK VTS. All that to simply get the
robot in the VTS to finally move (the actual data will flow over FICON).
Sun/STK tells me that the Linux server should be Redhat (Fedora?) Linux on
a Solaris box. I told them no way!; we will install a SuSE Linux virtual
machine (just like all the other Linux on zSeries servers we plan) in the
same z/VM system that needs access to the Sun/STK VTS. No firewalls. No
routers. No problems.
OTOH, Sun/STK will have to support their application in that environment.
They want our money, they need to support our environment. We'll see how
that all pans out. Man plans, God laughs.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Moore, Terry A." <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
05/31/2006 12:51 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
VM for DB2 Backups
Our data center is eliminating an STK tape silo and implementing STK's
Virtual Tape product. They tell me that there is no interface from VM for
STK Virtual Tape. The data center manager wants to know if we could take
DB2/VM backups from MVS (shared dasd environment). Our DBA has suggested
the alternate solution (below) for DB2/VM backups.
Has anyone got experience with doing DB2/VM backups in such an environment
or care to comment on either proposed solution?
Terry A. Moore
Proj Mgr - IT Infrastructure
Terry,
Here is the problem. We have several VM for DB2 database servers.
Currently they use vmbackup to take database and log backups using the
tape silo. The tape silo is being replaced by a virtual tape
machine(from STK). VM cannot talk to the virtual tape machine so
utilizing that is not an option. My thoughts currently are to take a
weekly backup of all the DB2 for VM database machines data disk utilizing
a FAT tape(s) and throughout the week take log backups for the database
machines that do online updating. I am still trying to test this
scenario to make sure it will work.
Currently, we use a product called VM:DBA from CA that allows us to
automate all the backups so no operator intervention is required. In
order to use FAT tape(s) to backup all the databases at one time, I will
create a vmbackup template that will have all the databases data disks and
then it will be submitted via an exec by VM:DBA after all the databases
have been brought down. The problem here is VM:DBA will not be able to
track when the backups are done and keep track of the volume serial
numbers use in the backup process so the restore process will now have to
a more manual process outside of the VM:DBA product. Also, a routine to
bring the databases back online after the backup is done will need to
created.
This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited.
