We¹re trying to create new Linux images just as fast as our geeky little
minds can comprehend, and the next logical step would be FlashCopy.
DirMaint appears to have parameters for the use of FlashCopy by the module
DVHDXD, but I can¹t find too much more information beyond what is documented
in
On Tuesday, 01/08/2008 at 09:03 EST, RPN01 [EMAIL PROTECTED] wrote:
We?re trying to create new Linux images just as fast as our geeky little
minds
can comprehend, and the next logical step would be FlashCopy.
DirMaint appears to have parameters for the use of FlashCopy by the
module
I hate it when people hide things under my nose.
On 1/8/08 8:46 AM, Alan Altmark [EMAIL PROTECTED] wrote:
I think there is an error in the doc. The default level 2 behavior is
(supposed to be) synchronous. DirMaint will poll, waiting until the
flashcopy is complete before reporting
Yes, that's a good question I have been wondering too.
I will add a new page device but this time starting from cyl. 1
I will let you know the result of this.
Thank you very much
Saludos,
José R. Barón
Dpto. Sistemas
CALCULO S. A.
Tel. 91 330 86 44
e-mail: [EMAIL PROTECTED]
P No imprima
I will make sure to format the entire disk before any further action prior
to add it as a page area.
Saludos,
José R. Barón
Dpto. Sistemas
CALCULO S. A.
Tel. 91 330 86 44
e-mail: [EMAIL PROTECTED]
P No imprima este e-mail si no es realmente necesario
-Mensaje original-
De: The IBM
I don't know if this is a problem now, butback in the old days...
1. Format the pack first. You can even format cyl 0
2. Alloc the pack second. It will lay down the bit pattern needed.
If you did the opposite, the format destroyed your alloc.
But that isn't your problem. I believe that
Well, I have been reading system directory and the fact of starting the page
area in cyl. 0 doesn't seem to be the cause of this problem. Originally the
system-defined system page area is defined as:
USER $PAGE$ NOLOG
MDISK A03 3390 000 END 520PAG R
So, we're going to define a new page device equally directory-defined
as
520PAG (that is, 0-END), then we're going to CPFMTXA FORMAT it and
then
ALLOCATE 1-3338 this time.
That's the correct process. The key point is to ensure that the entire
disk is CP-formatted with the CPVOL FORMAT command
It seems to me that when dirmaint is left at defaults for flashcopy
behavior 2 that it appears to adopt a polling process to check whether
the storage device has actually finished copying the volume in the
background before returning from DVHDXD. It essentially turns the
instantaneous point in
Thanks Alan;
The FLASHCOPY command was exactly what we needed, and works perfectly. Where
building a system with two 3390 mod 9 disks took about 18 minutes using DDR
for the copy, using FLASHCOPY produces a bootable system in 41 seconds.
Quite an improvement.
In the CONFIG DATADVH file, the
Personal experience follows: take with a grain of salt, YMMV, may induce
headaches in pregnant men, etc
It seems to me that when dirmaint is left at defaults for flashcopy behavior
2 that it appears to adopt a polling process to check whether the storage
device has actually finished copying the
On Tuesday, 01/08/2008 at 11:41 EST, RPN01 [EMAIL PROTECTED] wrote:
But, in the documentation for the FLASHCOPY CP command, if FlashCopy
version
2 hardware is in use, then all the commands are synchronous, no matter
what
the request was. The difference would only be noticed on FlashCopy
Actually, the key point is:
Ensure that the cylinders you _FORMAT_ with CPFMTXA for CP's use (as
PAGE,
SPOL, DRCT) match exactly the cylinders that you _ALLOCATE_ with
CPFMTXA
for those uses.
Much better worded. Yes, that's what I meant. Thanks, Mike.
IMHO, and as David implies, formatting
The key point is to ensure that the entire
disk is CP-formatted with the CPVOL FORMAT command in ICKDSF (CPFMTXA
calls DSF under the covers) before you let CP try to page to it.
Actually, the key point is:
Ensure that the cylinders you _FORMAT_ with CPFMTXA for CP's use (as PAGE,
SPOL, DRCT)
I am trying to apply a PTF to my z/VM 5.1 system
I received the PTF from an IBM FTP site, I received three files:
ftp4385.txt è I received this as an ASCII file
The next two files were defined as binary f 1024
vlst4385.bin
vptf4385.bin
Next I FTPed the above files to my z/VM system in
Dear List:
We are in the process of negotiating a license for IBM's z/VM
Performance Toolkit (PTK). I know that my current release of z/VM being
5.3.0 already ships the PTK as a disabled product in the SYSTEM CONFIG
file.
However, the first project that we need the PTK for will be on our z/VM
Hi Clifford,
I follow instructions Part 4. Service procedure in GC24-6099-00 z/VM V5.1
Guide for Automated Installation and Service available from
http://www.vm.ibm.com/pubs/index.html and use SERVICE and PUT2PROD execs.
Cheers
Graeme
- Original Message -
From: clifford jackson
and you did the
access 5e5 b
access 51d d
?
clifford
jackson
The problem is surely not related to missing ACCESS commands.
I would try to have a look at the VPTF file:
VMFPLCD SCAN * * ENV= VPTF4385 SERVLINK A (EOD
If VMFPLCD is unhappy, VMSES will not work.
I tried the VMFINFO command on one of my COR enveloppes too and I get
the same error. The
19 matches
Mail list logo
