Alyce,
As others have said
1) VM:Backup - HiDRo - for ALL full volume backups, except page packs.
2) VM:Backup - for ALL cms file backups, including RES packs.
2) VM:Spool - to back up ALL spool files
good luck
Bill Munson
VM System Programmer
Office of Information Technology
State of New
Hello all. I need a few lines of code for a D/R situation. I need to know,
in VM and Linux, if we are in a real D/R or in a
test D/R.
My plan is to default to a real D/R situation, then, if it's a test,
execute a command from operator
that asks if it is a test, and if so, place a variable
I think that if you set different SYSTEM_ID's in the SYSTEM CONFIG file for
each of your situations you can then code different TCPIP startups for each
SYSTEM_ID and it will 'automatically' use the start up for that particular
system. RSCS works the same way.
For other applications you can use the
We use different System Configuration files for each situation then run
a WHERERWE EXEC which checks the CPUID and FN from QUERY IPLPARMS,
having made that a class G command. The return code from WHERERWE can
then be checked.
-Original Message-
From: The IBM z/VM
We run the same configuration both live and at DR. The only 2 things don
e
different at DR are to manually FORCE off AUTOLOG2 (there is a 1 minute
delay which allows this to be easily done) and to manually XAUTOLOG
TCPIPDR (which runs in *addition* to the normal TCPIP stack).
AUTOLOG2 brings
Thanks All. Here's what I've come up with. I'm going to allow everything to
come up on D/R without intervention if it is a real disaster. If I am
testing, I will allow it all to come up, and
IP won't work, so I'll bring TCPIP and the linuxes down, and XAUTOLOG
AUTOLOG2 Storage 6M. This way, if I'm
Our disaster backup process stores a control file on AUTOLOG1 191 when the
backup of that minidisk is taken (a very short while) and it is erased
afterwards. The PROFILE EXEC of AUTOLOG1 checks for the presence of this
file, if found; it prompts the operator to ask if it is really an IPL after
a
This is where it would be nice to be able to set (via SYSTEM CONFIG) an
arbitrary name with an arbitrary value and be able to query it from any
virtual machine. But without that we have to usurp other functions. I use
the GATEWAY value, setting it in the system config based on which CPU I i
pl
Or, what about an arbitrary parameter the operator could pass on the SAPL
screen (alongside CONS=xxx etc) that one could query, e.g; IPLREASON=.
Because: maintaining an extra SYSTEM CONFIG is often forgotten.
2007/10/3, Thomas Kern [EMAIL PROTECTED]:
This is where it would be nice to be
I like that even better since at DR I always have to use the SAPL screen
to
get my system console right. Just add the extra NAME=Value entries righ
t
there. And it should not be restricted to a single predefined variable na
me,
but let me do IPLCODE=xx IPLREASON='DR Recovery at YY'.
/Tom
I am very happy with using TSM client to backup files from our linux syst
ems
to the z/OS.e TSM server. It does use a lot of CPU time to scan all of th
e
files, compress them (if we let it) and send them to the server. The netw
ork
time will get reduced when we can get z/OS.e to learn how to talk
We are running TSM on an AIX...so I would have to backup Linux
files to it rather than z/OS. Is anyone using TSM on AIX
to backup Linux at the file level?
Thanks,
Alyce
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent:
Hello Alan,
Sorry I have not had time to work on this.
I have the sendfile email function working to all AULTMAN.COM users.
Now I have a relay problem, but I am working on it again.
TECHVSE1.AULTMAN.COM unable to deliver following mail to recipient(s):
[EMAIL PROTECTED]
Don't sweat it. Like any good client-server protocol, the TSM client
doesn't care much about which OS the daemon is running on as long as
it's at current levels.
(Yes, I'm aware of the irony of writing this on a VM list.)
Nick
Austin, Alyce (CIV) wrote:
We are running TSM on an AIX...so I
We have the PROFILE EXEC for AUTOLOG1 coded to stop and ask the
operator whether to continue normal startup or not every time we IPL.
In addition, the operator can use the SM reply to tell AUTOLOG1 to
carry on but that we are in a disaster recovery.
Like Kris, AUTOLOG1 does different things based
Ron, that's fine for DR tests, but we need to be able to come up
automagically
if we're all gone in a real DR, so our main 'goal' is to run as if it's a
real DR and get the
whole way up with no intervention. So I'll have autolog come up, it will
fail, and in a test
I'll force the linuxes and
Another (prewritten) option would be to use the SYSVINIT code we developed for
AUTOLOG1 use. You could define a runlevel for DEFAULT (your normal setup) and
DISASTER (the disaster setup). SYSVINIT allows persistent variable setting, and
it wouldn't be hard to look for a specific result from the
That's on the other end from you. techvse1.autlmann.com needs to be configured
to add you to the list of ip addresses that is permitted to relay via techvse1.
That's going to be on the relay system itself, usually in /etc/mail/access if
it's a unix box.
From:
You actually already have what you need, perhaps just not enough
experience with z/VM yet to use it to best advantage.
From a session that I've presented at SHARE called z/VM Installation -
It's Installed, NOW What?
---snip---
Slide 43:
? We?ll go though ?Record Qualifiers? quickly as it
Mike, that's an excellent (and colorful) explanation and works really
well if you are doing 2 sites in different places (or lpars).
I think Mary Anne is looking at the same problem I am now. We have
primary and then another site that is both disaster test and real
disaster site. So the
20 matches
Mail list logo
