On Wednesday, 08/27/2008 at 07:48 EDT, Thomas Kern [EMAIL PROTECTED]
wrote:
If the VM stack and the linux stack were both connected to a VSWITCH,
would monitoring function in the physical switch see that clear text
data is being transfered from VM to linux?
No. Data is sent directly to the
:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Friday, August 22, 2008 5:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 08/20/2008 at 03:20 EDT, Michael Coffin
[EMAIL PROTECTED] wrote:
I'm not in front of a VM terminal, so forgive me
On Wednesday, 08/27/2008 at 06:20 EDT, Michael Coffin
[EMAIL PROTECTED] wrote:
Oh Drat. :(
We have a mandate that ALL FTP must be secure FTP, and it's going to be
enforced very (VERY) soon. We may have to continue doing the darned
intermediate file method in order to use the CMS FTP
If the VM stack and the linux stack were both connected to a VSWITCH,
would monitoring function in the physical switch see that clear text
data is being transfered from VM to linux?
/Tom Kern
Alan Altmark wrote:
On Wednesday, 08/27/2008 at 06:20 EDT, Michael Coffin
[EMAIL PROTECTED] wrote:
On Wednesday, 08/20/2008 at 03:20 EDT, Michael Coffin
[EMAIL PROTECTED] wrote:
I'm not in front of a VM terminal, so forgive me is this is documented -
but is secure FTP supported? I don't recall seeing a parm for it
(doesn't mean it's not there and I didn't see it). :)
Not in the
¿SPXTAPE will support dump to disk in the future?
Thanks
2008/8/20 Dave Jones [EMAIL PROTECTED]
Hi, Jiri.
This is way cool, many thanks for doing the work and sharing it. I think
it's going to make life a bit easier for some folks.
Some suggestions:
1) There seems to be an undocumented
This is huge! Thanks Jiri!
If we were all on FBA, then copying disks would be as trivial as
copying files because the disk would be must a big block-o-bytes.
But since z/VM is still saddled with ye olde CKD tricks because of
the indirect influence of z/OS, this new ability to *convert* a disk
(Steven) Imler
CA
Senior Sustaining Engineer
Tel: +1 703 708 3479
[EMAIL PROTECTED]
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jim Bohnsack
Sent: Wednesday, August 20, 2008 09:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote
@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Hi, Jiri.
This is way cool, many thanks for doing the work and sharing it. I think it's
going to
make life a bit easier for some folks.
Some suggestions:
1) There seems to be an undocumented option in at least the FTPGET stage
¿SPXTAPE will support dump to disk in the future?
There's a requirement for supporting PIPE connections like the DDR mods that
were just made available. Status is unknown at the moment other than IBM has
seen it and seems to understand the desire for the function, but hasn't made
any
Jiri and Bruce -
What is the minimun level of VM required to run DRPC and PIPEDDR?
I have been trying unsuccessfully to run both in z/VM 3.1.
I have tried with both the CMS Pipelines and the Princeton Runtime
Pipes.
pipe ddr dump195 ddrin a | 195 dump c
DMSABE141T Operation exception occurred
Your PIPEDDR syntax would be:
pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr
I forgot to put ftp examples in the help when I sent it. They are in
there for the next update.
A restore could be:
pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx
to me.. Another step towards a tapeless society.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Dave Jones
Sent: Wednesday, August 20, 2008 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Hi, Jiri
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Imler, Steven J
Sent: Thursday, August 21, 2008 4:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
CA's V/Seg does backup
Dave Jones' SFB VMARC is now on my download page at
http://zvm.sru.edu/~download
or
http://zvm.sru.edu/~download/SFB.VMARC
As Dave says in his DOC:
The normal distribution is for z/VM 5.1 5.2 and 5.3
I haven't been able to get it to work in z/VM 3.1 .
Note that the download may be slow
I now have running on z/VM 3.1 PIPEDDR, FTPPUT and FTPGET.
Thanks Bruce,
/Fran
---
On Thu, 21 Aug 2008 11:10:27 -0400 Bruce Hayden said:
Your PIPEDDR syntax would be:
pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p
Hello,
In its current implementation DRPC requires z/Architecture and therefore it
will not run under z/VM 3.1. I'll try to look at the code again, see if I
can change this, but it will probably require a bit of work.
-George
z/VM I/O Development
IBM Endicott
The IBM z/VM Operating System
Hi, Jiri.
This is way cool, many thanks for doing the work and sharing it. I think it's going to
make life a bit easier for some folks.
Some suggestions:
1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of
course, this might have meaning only in the case
Since the DRPC package has now made the ftpget/ftpput stages available
and documented them, I added an ftp option to my PIPEDDR package so
that disks can be dumped and restored to and from and ftp server. You
can find it at http://www.vm.ibm.com/download/packages/descript.cgi?pipeddr
via the
] On
Behalf Of Jiri Stehlik
Sent: Tuesday, August 19, 2008 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to
remote location. Well there is an answer! I modified DDR so it can
communicate with CMS
I'm surprised that your posting about being able to backup/restore
DCSS/NSS files to disk was not jumped on by a lot of people. I'd love
to have that. Does it/can it restore the original creation DCSS/NSS
date? The date problem and the fact that IBM's DCSSBKUP only works
with DCSS's, not
A while ago there was a thread here about the ability to DDR DASD to remote
location. Well there is an answer! I modified DDR so it can communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded from here:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
Waw, that sounds great.
2008/8/19 Jiri Stehlik [EMAIL PROTECTED]:
A while ago there was a thread here about the ability to DDR DASD to remote
location. Well there is an answer! I modified DDR so it can communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded
A while ago there was a thread here about the ability to DDR DASD to
remote
location. Well there is an answer! I modified DDR so it can
communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded from here:
?).
Thanks George, can't wait to try it out! :)
-Mike
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jiri Stehlik
Sent: Tuesday, August 19, 2008 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DDR'ing 3390 DASD To Remote Location
A while ago
Hi Dave,
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
Yep, George has been working on this project with that exact requirement
in mind. Considering the recent discussions here on this very topic, we
Yep, George has been working on this project with that exact
requirement in mind.
Fantastic. That's exactly what I wanted to hear.
Q: does this version also include the CMSDDR mods?
No, this is an otherwise unmodified DDR module.
Yeah, about 3 seconds after hitting send I realized that
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED]
wrote:
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
LOL. George left one small thing off of his signature:
z/VM I/O Development
IBM
Details details details.!
Thanks
Alan Altmark wrote:
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED]
wrote:
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
LOL.
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
The FTPPUT and FTPGET PIPE stages were also included and documented at the
above address.
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
The FTPPUT and FTPGET PIPE stages were also included and documented
at the
above address.
I have the latest CMS PIPLINES but it
LOL. George left one small thing off of his signature:
z/VM I/O Development
IBM Endicott
Alan Altmark
z/VM Development
IBM Endicott
Well, far be it from me that I suggest that VM Development begin to talk
to themselves. You lot 're odd enough to begin with...8-)
-- db
Hello,
I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So once
you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get
registered.
-George
(on Alan's insistance):
z/VM I/O Development
IBM Endicott
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
On Aug 19, 2008, at 1:48 PM, David Boyes wrote:
Well, far be it from me that I suggest that VM Development begin to
talk
to themselves. You lot 're odd enough to begin with...8-)
As Zork so eloquently put it, Talking to yourself is said to be a
sign of impending mental collapse.
Adam
As Zork so eloquently put it, Talking to yourself is said
to be a sign of impending mental collapse.
You see, I was never worried about it when I talked to myself.
I only started to wonder when I started ANSWERING myself. That's
when even the wife and kids leave the room and stay out of my
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on the IBM Download site either.
Where can I get them?
On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said:
Run INSTPIPE MODULE from MAINT 2CC.
I'm
As Zork so eloquently put it, Talking to yourself is said to be a sign
of impending mental collapse.
I prefer to think of this as discussing the problem with the person who
understands it the best. That's my story and I'm sticking with it.
Nora Graves
On Aug 19, 2008, at 2:29 PM, Fran Hensler wrote:
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on the IBM Download site either.
Where can I get them?
On Tue, 19 Aug 2008 13:48:20 -0500 Adam
Now if we could get the TERSE/DETERSE stages added, we might get these du
mps
down to a better size for transferring cross-country.
/Tom Kern
/301-903-2211
On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro
te:
Hello,
I compiled the FTPPUT and FTPGET pipe stages into the
@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Now if we could get the TERSE/DETERSE stages added, we might
get these du= mps down to a better size for transferring
cross-country.
/Tom Kern
/301-903-2211
On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik
[EMAIL
Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then
reading then, compressing them and writing them as cms files is too much
I/O
for the process. A pipe stage to properly compress the piped input is
necessary for efficiency. The PACK stage can be used but it doesn't buy y
ou
No. it doesn't. Keep plugging for a way.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern
Sent: Tuesday, August 19, 2008 1:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD
] On
Behalf Of Jiri Stehlik
Sent: August 19, 2008 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to remote
location. Well there is an answer! I modified DDR so it can communicate
with CMS PIPES (DDR
On Wednesday, 06/18/2008 at 01:01 EDT, McKown, John
[EMAIL PROTECTED] wrote:
If this is like some things in z/OS, the response from IBM development
will be along the lines of: It is not documented because we don't want
anyone else to use it. We don't want others to use it because if they
do,
Of Alan Altmark
Sent: Friday, June 20, 2008 1:07 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 06/18/2008 at 01:01 EDT, McKown, John
[EMAIL PROTECTED] wrote:
If this is like some things in z/OS, the response from IBM development
will be along
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Friday, June 20, 2008 9:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Wouldn't it be 'nice' if things like that were 'available
:[EMAIL PROTECTED] On
Behalf Of McKown, John
Sent: June 20, 2008 10:31
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Friday, June 20, 2008 9:04
To Remote Location
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas
Sent: Friday, June 20, 2008 9:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Wouldn't it be 'nice' if things like
If source code were available for all of the entries on the IBM Downloads
website, then groups of people wanting to use some function in production
could take over the support of the code.
Sort of like the Waterloo Mods and VMShare, we can fix/enhance the code
together.
/Tom Kern
On Fri, 20
Just like Open Source. :)
-Mike
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Friday, June 20, 2008 11:02 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
If source code were available
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin
Sent: Friday, June 20, 2008 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Just like Open Source. :)
-Mike
Yeah, but WHICH
The VM community shared a lot more code before people started worrying ab
out
licensing. I don't remember anyone making money off of the Waterloo Mods.
/Tom Kern
On Fri, 20 Jun 2008 13:27:35 -0500, McKown, John
[EMAIL PROTECTED] wrote:
Yeah, but WHICH LICENSE? There are a LOT of them. And the
On Fri, Jun 20, 2008 at 3:41 PM, in message
[EMAIL PROTECTED], Thomas Kern
[EMAIL PROTECTED] wrote:
The VM community shared a lot more code before people started worrying about
licensing. I don't remember anyone making money off of the Waterloo Mods.
And most of that was before the Berne
PROTECTED] On
Behalf Of Tom Duerbusch
Sent: Tuesday, June 17, 2008 3:42 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
It depends on your recovery window.
In the shop where we don't have disaster recovery tests, the window is
officially 3 months, but I have
Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Aria Bamdad
Sent: Tuesday, June 17, 2008 1:44 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said:
Hi Aria,
We are on an IBM 2066-0B1 with ESCON channels to an IBM
System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, June 18, 2008 11:25 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE'
supports VTAPEs.
-Original Message-
From: The IBM
/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin
Sent: Wednesday, June 18, 2008 8:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial
product and already runs on VM
On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote:
Hi Tom,
Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever
come
across such a generous recovery window, most companies would be
out of
business in 3 months without access to their mission-critical systems.
:)
On another
too.
Ed Martin
330-588-4723
ext 40441
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Coffin
Sent: Wednesday, June 18, 2008 11:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
VTAPE is a Virtual
it. But why not in
z/VM?
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Michael Coffin
Sent: Wednesday, June 18, 2008 10:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
VTAPE is a Virtual Software Systems, Inc
: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Ed Zell
Sent: Wednesday, June 18, 2008 11:13 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
That is excatally what it can do in VSE.. Point the
output to an IP address where the client is running
3 months was chosen back in the early '80s.
This is local government.
As Mel Brooks would say: It's good to be the king!
Subject: Re: DDR'ing 3390 DASD To Remote Location
On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote:
Hi Tom,
Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever
come
across such a generous recovery window, most companies would be
out of
business in 3 months without access
Hi Michael,
we use as DR a VTL from BusTech, the MAS. So, we have FICON attached a MAS,
and we write our tapes in normal
open systems disks. Then, the reseller here in Germany, mainstorconcept,
installed also a replication module over IP and now we have all the virtual
tapes in a second
DR
Of [EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 12:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Yes, Adam is quite correct, the new install procedures for z/VM (at
least for the past couple of releases) does employ an undocumented FTP
PIPE stage. I don't
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin
Sent: Wednesday, June 18, 2008 11:49 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Well ain't this a kick in the pants! Yes indeed
that might
provide a clue as to what parms are required and/or supported.
-Mike
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 12:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD
Something I have done in the past is to use DoctorD in
VSE which has a feature to create standalone DDR'ish
backups of VM volumes.. That way they are labeled and
in the EPIC catalog too. It worked fine in DR tests,
back when we used real tapes.
Tom,
We also have Doctor D on VSE, and I
and then use FCOPY to restore the VM system. No DDR just standalone FCOPY.
Hans
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Zell
Sent: June 18, 2008 1:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
(Cross-posted on VMESA-L and LINUX-390)
Hi Folks,
I want to eliminate use of tapes in my weekly DR process. Currently we
DDR numerous 3390 spindles to 3590 tape cartridges.
I have set up a Linux server at our DR site with a ton of free disk
space, but the question becomes what is the best
On Jun 17, 2008, at 10:42 AM, Michael Coffin wrote:
Can anyone recommend a nice client that can run on Linux and listen
on a TCPIP port, accept some authorization credentials and host
commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a
stream of data similar to what
When experimenting with encrypting backups, I used PIPEDDR to write PACKE
D
versions of the data to a CMS minidisk. These are RECFM F LRECL 1024 and
can
be ftped to Linux and back as binary files, forcing the RECFM/LRECL on
return. PIPEDDR can then be used to read these files and restore your DAS
Mike Coffin wrote:
so I have to COPYFILE (PACK the output from DDR2CMS
Neatly avoiding the direct question, in case no one can provide the
requested solution...
have you tried using a PIPE to read in the DDR2CMS file, run it through
the PACK stage, and replace it on disk?
It *may* be faster
Sent: Tuesday, June 17, 2008 12:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Mike Coffin wrote:
so I have to COPYFILE (PACK the output from DDR2CMS
Neatly avoiding the direct question, in case no one can provide the
requested solution...
have you tried using
System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Tuesday, June 17, 2008 11:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
When experimenting with encrypting backups, I used PIPEDDR to write
PACKED versions of the data to a CMS minidisk
The back half of this also needs to be considered.
In case of an actual disaster, the process you are using requires a running VM
system before you can do the restore. Disaster recovery sites have VM running.
If you have your own replacement hardware, you can bring up the VM starter
system,
If you have your own hotsite, you can prestage a copy of the 530RES, 530W
01,
etc volumes and have all of your special code on that system. Or a more
compact 1 volume DR recovery system, a 3390-m9 is MORE than enough space.
/Tom Kern
/U.S. Dept of Energy
/301-903-2211
On Tue, 17 Jun 2008
This is where it would be nice if Linux had a special filesystem driver f
or
WRITING CMS minidisks.
Yes, DOE purchased an ATL of the new encrypting tape drives that z/VM can
not
directly use because of the lack of an out-of-band EKM at our DR vendor.
So
z/OS performs ALL of our backups, at least
Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Duerbusch
Sent: Tuesday, June 17, 2008 12:31 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
The back half of this also needs to be considered.
In case of an actual disaster
On Tue, 17 Jun 2008 11:42:13 -0400 Michael Coffin said:
have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around
47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP
only takes around 17 minutes! So we are really wasting nearly 90
minutes/spindle just prepping the
:[EMAIL PROTECTED] On
Behalf Of Aria Bamdad
Sent: Tuesday, June 17, 2008 12:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
On Tue, 17 Jun 2008 11:42:13 -0400 Michael Coffin said:
have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around
47 minutes
PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
I do like the monkey boy concept. I keep trying to go towards that
state.
You have a menu driven system, which implies you are not restoring to
bare iron. So what was prestaged? Do you have a mini VM system
The added cycles for software encryption is a problem for me also.
I use an drive enclosure made by Addonics that encrypts everything on
the drive using various levels of encryption. It's all hardware based
and to get to the data on the drive, you need to plug in the encryption
key before you
for the kind words, too.
DJ
Original Message:
-
From: Michael Coffin [EMAIL PROTECTED]
Date: Tue, 17 Jun 2008 13:38:01 -0400
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To Remote Location
Hi Tom,
Yep, we were also looking at Dave's VM/Encrypt product and I REALLY
84 matches
Mail list logo
