Re: CPFMTXA VOLUME FORMATTING QUESTION

[Schuh, Richard]

That last makes for a good question. I do not have any guests other than
CMS, GCS and TPF varieties, so I have no way to trace to see if it is
still a problem. The only time I encountered it was in a non-VM shop.
Fortunately, we were able to wrest the disk away from the system before
there was any real harm. I had the onerous task of restoring the dummy
VTOC using the then state of the art IEHDASDR and SuperZap. 

I cannot reproduce the situation here. The DASD Storage Management folks
are adamant about not having VM volumes accessible to z/OS and
vice-versa, which suits me just fine. That eliminates the only system I
know of that has the potential to cause the problem.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Monday, September 29, 2008 1:33 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION
> 
> On Monday, 09/29/2008 at 02:06 EDT, "Schuh, Richard" <[EMAIL PROTECTED]>
> wrote:
> > Unless things have changed in the last few years, the VTOC written 
> > when formatting the disk as a CPVOL does not go far enough. 
> If the MVS 
> > DASD Storage Allocation Routine is interrupted while the 
> checking for 
> > free space on the volume, a bit (formerly known as the DADSM 
> > Interruption Bit or DOS VTOC bit, currently known as the 
> VSE bit, name 
> > DS4DOSBT in the F4 DSCB DSECT) is left on. The next time 
> MVS attempts 
> > to allocate space on the volume, it will try to create proper free 
> > space records. It does this buy starting with an F5 DSCB that shows 
> > all space available on the disk. It then runs the F1 and F3 chains, 
> > allocating each described extent. Since there are no 
> allocated extents 
> > on a CPVOL formatted disk, it shows the entire volume as 
> being available for space allocation.
> > There needs to be at least 1 F1 DSCB allocating the entire 
> volume to a 
> > space-holder dataset to prevent this highly unlikely occurrence.
> 
> You need to open a PMR with the ICKDSF team on this if you're 
> interested in getting it fixed (assuming it is still a problem).
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Alan Altmark]

On Monday, 09/29/2008 at 02:06 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> Unless things have changed in the last few years, the VTOC written when
> formatting the disk as a CPVOL does not go far enough. If the MVS DASD
> Storage Allocation Routine is interrupted while the checking for free
> space on the volume, a bit (formerly known as the DADSM Interruption Bit
> or DOS VTOC bit, currently known as the VSE bit, name DS4DOSBT in the F4
> DSCB DSECT) is left on. The next time MVS attempts to allocate space on
> the volume, it will try to create proper free space records. It does
> this buy starting with an F5 DSCB that shows all space available on the
> disk. It then runs the F1 and F3 chains, allocating each described
> extent. Since there are no allocated extents on a CPVOL formatted disk,
> it shows the entire volume as being available for space allocation.
> There needs to be at least 1 F1 DSCB allocating the entire volume to a
> space-holder dataset to prevent this highly unlikely occurrence.

You need to open a PMR with the ICKDSF team on this if you're interested 
in getting it fixed (assuming it is still a problem).

Alan Altmark
z/VM Development
IBM Endicott

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Schuh, Richard]

CPFMTXA/ICKDSF will put a VTOC on the system that shows no space
available. I know of nothing that also shows all space allocated. Both
are needed to prevent allocation and insure that the VSE Bit can never
cause a problem.
 

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Rohling
Sent: Monday, September 29, 2008 11:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION


A colleague here supposedly wrote something that puts a 1 track
DSCB on cylinder 0 that shows it with no free space to MVS.. but no one
can find it :-)I've been hunting around for such a thing because the
backups of the VM volumes that are supposed to take place on MVS are
getting skipped... (the details are sketchy but it's related to having a
valid VTOC and space being used)

Does anybody have some code they can share that does such a
thing (make the volume visible to z/OS with a valid VTOC and show the
volume as being used?)

Thanks !

Scott Rohling


On Mon, Sep 29, 2008 at 11:46 AM, Schuh, Richard
<[EMAIL PROTECTED]> wrote:


Only if the volume label points to somewhere that used
to be a VTOC that
has not been overwritten.

Unless things have changed in the last few years, the
VTOC written when
formatting the disk as a CPVOL does not go far enough.
If the MVS DASD
Storage Allocation Routine is interrupted while the
checking for free
space on the volume, a bit (formerly known as the DADSM
Interruption Bit
or DOS VTOC bit, currently known as the VSE bit, name
DS4DOSBT in the F4
DSCB DSECT) is left on. The next time MVS attempts to
allocate space on
the volume, it will try to create proper free space
records. It does
this buy starting with an F5 DSCB that shows all space
available on the
disk. It then runs the F1 and F3 chains, allocating each
described
extent. Since there are no allocated extents on a CPVOL
formatted disk,
it shows the entire volume as being available for space
allocation.
There needs to be at least 1 F1 DSCB allocating the
entire volume to a
space-holder dataset to prevent this highly unlikely
occurrence.

Regards,
Richard Schuh




> -Original Message-
> From: The IBM z/VM Operating System

> [mailto:[EMAIL PROTECTED] On Behalf Of Mike
Walter
> Sent: Monday, September 29, 2008 9:18 AM
> To: IBMVM@LISTSERV.UARK.EDU

        > Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION
>
> What about the dummy VTOC that CPFMTXA (or ICKDSF's
CPVOL
> command) places on cylinder zero?
> Without that dummy VTOC, which makes it appear to
Other
> Systems that there is no space left on the DASD, they
can and
> **WILL* write on it!

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Howard Rifkind]

Thanks for all the replies...

>>> Aria Bamdad <[EMAIL PROTECTED]> 9/29/2008 11:34 AM >>>
When you use CPFMTXA command, you can specify the from/to cylinder
for your format command.  Specify cyl 0 and then properly allocate the
device as PERM.

As a general procedure, I do not attach any new device to my system
before I CPFMTXA the complete volume.

_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Scott Rohling]

A colleague here supposedly wrote something that puts a 1 track DSCB on
cylinder 0 that shows it with no free space to MVS.. but no one can find it
:-)I've been hunting around for such a thing because the backups of the
VM volumes that are supposed to take place on MVS are getting skipped...
(the details are sketchy but it's related to having a valid VTOC and space
being used)

Does anybody have some code they can share that does such a thing (make the
volume visible to z/OS with a valid VTOC and show the volume as being used?)

Thanks !

Scott Rohling

On Mon, Sep 29, 2008 at 11:46 AM, Schuh, Richard <[EMAIL PROTECTED]> wrote:

> Only if the volume label points to somewhere that used to be a VTOC that
> has not been overwritten.
>
> Unless things have changed in the last few years, the VTOC written when
> formatting the disk as a CPVOL does not go far enough. If the MVS DASD
> Storage Allocation Routine is interrupted while the checking for free
> space on the volume, a bit (formerly known as the DADSM Interruption Bit
> or DOS VTOC bit, currently known as the VSE bit, name DS4DOSBT in the F4
> DSCB DSECT) is left on. The next time MVS attempts to allocate space on
> the volume, it will try to create proper free space records. It does
> this buy starting with an F5 DSCB that shows all space available on the
> disk. It then runs the F1 and F3 chains, allocating each described
> extent. Since there are no allocated extents on a CPVOL formatted disk,
> it shows the entire volume as being available for space allocation.
> There needs to be at least 1 F1 DSCB allocating the entire volume to a
> space-holder dataset to prevent this highly unlikely occurrence.
>
> Regards,
> Richard Schuh
>
>
>
> > -Original Message-
> > From: The IBM z/VM Operating System
> > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
> > Sent: Monday, September 29, 2008 9:18 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION
> >
> > What about the dummy VTOC that CPFMTXA (or ICKDSF's CPVOL
> > command) places on cylinder zero?
> > Without that dummy VTOC, which makes it appear to Other
> > Systems that there is no space left on the DASD, they can and
> > **WILL* write on it!
>

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Schuh, Richard]

Only if the volume label points to somewhere that used to be a VTOC that
has not been overwritten. 

Unless things have changed in the last few years, the VTOC written when
formatting the disk as a CPVOL does not go far enough. If the MVS DASD
Storage Allocation Routine is interrupted while the checking for free
space on the volume, a bit (formerly known as the DADSM Interruption Bit
or DOS VTOC bit, currently known as the VSE bit, name DS4DOSBT in the F4
DSCB DSECT) is left on. The next time MVS attempts to allocate space on
the volume, it will try to create proper free space records. It does
this buy starting with an F5 DSCB that shows all space available on the
disk. It then runs the F1 and F3 chains, allocating each described
extent. Since there are no allocated extents on a CPVOL formatted disk,
it shows the entire volume as being available for space allocation.
There needs to be at least 1 F1 DSCB allocating the entire volume to a
space-holder dataset to prevent this highly unlikely occurrence.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
> Sent: Monday, September 29, 2008 9:18 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION
> 
> What about the dummy VTOC that CPFMTXA (or ICKDSF's CPVOL 
> command) places on cylinder zero?
> Without that dummy VTOC, which makes it appear to Other 
> Systems that there is no space left on the DASD, they can and 
> **WILL* write on it!

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Brian Nielsen]

As others have pointed out, yes you can just format cylinder zero.  Soon 

after I started at this site I ran across a volume that have not been 
formated with CPVOL.  I wrote the following Q-ALLOCM EXEC to check all th
e 
DASD to find out how widespread the problem was and found 68 out of 354 

volumes in need of attention.  I minor tweak produced FMT-CYL0 EXEC, also
 
included below, to fix them all.

--- Start Q-ALLOCM EXEC 

/* */
'PIPE CMS ERASE Q-ALLOC CPFMTXA A | HOLE'
'PIPE CMS ERASE Q-ALLOC OUTPUT A | HOLE'

/* DASD 662B CP SYSTEM VM322B   11  */
'PIPE',
   'CP Q DASD',
   '| SPECS W2 1 W5 NW',
   '| STEM DASD.'

DO i=1 TO dasd.0
   parse var dasd.i raddr volid .
   CALL get_alloc_map raddr volid
END

EXIT

CALL get_alloc_map 674d VM674d
CALL get_alloc_map 662b VM322b


/* - */
get_alloc_map: PROCEDURE
   arg raddr volid .

   'PIPE CP DEFINE MDISK' raddr '0 1' volid '| HOLE'

   say 'CPFMTXA' raddr volid 'ALLOCATE'
   MAKEBUF
   push 'END'
   'PIPE (ENDCHAR ?)',
  'CMS CPFMTXA' raddr volid 'ALLOCATE',
  '| >> Q-ALLOC CPFMTXA A',
  '| l: LOCATE ICK33001I',
  '| f: FANINANY',
  '| SPECS /'raddr'/ 1 1-* NW',
  '| >> Q-ALLOC OUTPUT A',
  '?',
  'l:',
  '| LOCATE ICK03021I',
  '| f:'

   DROPBUF

   'PIPE CP DET' raddr '| HOLE'

RETURN

 End Q-ALLOCM EXEC 

The above produces a file that lookes like:

 Q-ALLOC  OUTPUT   A1  V 80  Trunc=80 Size=354 Line=0 Col=1 Alt=
0

  |...+1+2+3+4+5+6
= * * * Top of File * * *
= 6400 ICK33001I VM6400 CYLINDER ZERO NOT IN CP FORMAT
= 6401 ICK03021I 6401 IS FORMATTED FOR VM/XA|ESA MODE
= 6402 ICK03021I 6402 IS FORMATTED FOR VM/XA|ESA MODE
= 6403 ICK33001I VM6403 CYLINDER ZERO NOT IN CP FORMAT
= 6404 ICK33001I VM6404 CYLINDER ZERO NOT IN CP FORMAT
= 6405 ICK33001I VM6405 CYLINDER ZERO NOT IN CP FORMAT

A couple edit commands removes all the volumes already in VM format:
   ALL /ESA MODE/
   DELETE *
   ALL
   TOP
   SAVE = NOT-CP A

and saves the file which looks like this and is used as input to FMT-CYL0
:


 Q-ALLOC  NOT-CP   A1  V 80  Trunc=80 Size=68 Line=0 Col=1 Alt=
0

  |...+1+2+3+4+5+6
= * * * Top of File * * *
= 6400 ICK33001I VM6400 CYLINDER ZERO NOT IN CP FORMAT
= 6403 ICK33001I VM6403 CYLINDER ZERO NOT IN CP FORMAT
= 6404 ICK33001I VM6404 CYLINDER ZERO NOT IN CP FORMAT
= 6405 ICK33001I VM6405 CYLINDER ZERO NOT IN CP FORMAT


 Start FMT-CYL0 EXEC 

/* */
'PIPE CMS ERASE FMT-CYL0 CPFMTXA A | HOLE'

/* DASD 662B CP SYSTEM VM322B   11  */
'PIPE',
   '< Q-ALLOC NOT-CP A',
   '| SPECS W1 1 W3 NW',
   '| STEM DASD.'

DO i=1 TO dasd.0
   parse var dasd.i raddr volid .
   CALL fmt_cyl_0 raddr volid
END

EXIT

CALL fmt_cyl_0 674d VM674d
CALL fmt_cyl_0 662b VM322b


/* - */
fmt_cyl_0: PROCEDURE
   arg raddr volid .

   'PIPE CP DEFINE MDISK' raddr '0 END' volid '| HOLE'

   say 'CPFMTXA' raddr volid 'FORMAT'

   MAKEBUF
   push 'END'
   push 'YES'
   'PIPE (ENDCHAR ?)',
  'CMS CPFMTXA' raddr volid '0.1',
  '| >> FMT-CYL0 CPFMTXA A'

   DROPBUF

   'PIPE CP DET' raddr '| HOLE'

RETURN

 End FMT-CYL0 EXEC 


Both EXECs also include some unreachable CALLs which can be used instead 

of doing a full Q DASD in Q-ALLOCM or processing the full list from FMT-
CYL0.

Brian Nielsen



On Mon, 29 Sep 2008 11:24:39 -0400, Howard Rifkind <[EMAIL PROTECTED]
> 
wrote:

>Hello all,

 

I have a new DASD address which has to be added to z/VM 5.3 which was 
previously formatted with a z/OS format.

 

I didn't do a CPFMTXA format.

 

I attached the volume to system and DDR'ed a few minidisks over to the ne
w 
volume.

 

So, cylinder 0 of the new volume is not in CP format.  The copied 
minidisks are O.K and I would hate to do the copies again.

 

Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire 

volume as PERM without loosing the copied minidisks?

 

Thanks.

 

_

LEGAL NOTICE

Unless expressly stated otherwise, this message is confidential

and may be privileged. It is intended for the addressee(s) only.

Access to this E-mail by anyone else is unauthorized.

If you are not an addressee, any disclosure or copying of the

contents of this E-mail or any action taken (or not taken) in

reliance on it is unauthorized and may be unlawful. If you are not an

addressee, please inform the sender immediately, then delete this

message and empty from your trash.

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Mike Walter]

What about the dummy VTOC that CPFMTXA (or ICKDSF's CPVOL command) places 
on cylinder zero?
Without that dummy VTOC, which makes it appear to Other Systems that there 
is no space left on the DASD, they can and **WILL* write on it!

From: 
http://listserv.uark.edu/scripts/wa.exe?A2=ind9709&L=IBMVM&P=R14050&I=-3&X=72B31F0083433ED14B&Y=mike.walter%40hewitt.com
--
It was the Monday, the VM/SP 1 system was up and running with
almost 30 users (just about the high end way back then) when it
crashed.  After it came up I loaded the dump and just had a chance to
see the registers - which looked very strange, when it crashed again.
After it came up, checked the dump again and registers 1 and 2
contained: C3C8C5C5 E2C54B40.   A rather unusual set of addresses in
pre-XA days, and pretty unlikely even now.  It took only moments for
the light to come on; R1 and R2 contained EBCDIC for 'CHEESE. '!  I
loaded up the second dump and just had time to see another set of
registers (not sure if it was R1-R2 or R11-R12) which contained
D9C5D7D6 D9E34040.  That translated to 'REPORT  '.  For some reason
something clicked and I ran down to the data center to check.  Sure
enough, one of our just-added page volumes was mounted as 'PUBLIC' on
one of the MVS systems. Another group was responsible for running
CPFMT and adding new DASD to the system.  We usually double-checked
their work, but this case missed checking the new page volume.  It
had been INITed, but they had neglected to run CPFMT to place the
dummy VTOC on it.  So to MVS it looked empty, while VM paged out to
that volume, MVS wrote temporary datasets on it, which VM paged in
and tried to load as executable instructions.  I still refer to this
as the time the system crashed because there was CHEESE in the
registers (sounds like a hardware problem)!
--

I think we were the only VM customer to ever crash a VM system because we 
had cheese in our registers.
It gummed up the works pretty well!  ;-0

We were fortunate that the data loaded back from DASD was fairly obvious. 
It could have been much more difficult to resolve.

Moral: ALWAYS format VM DASD with CPVOL - at __LEAST__ cylinder zero.
"Trust, but verify"!

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.









"Schuh, Richard" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" 
09/29/2008 10:33 AM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: CPFMTXA VOLUME FORMATTING QUESTION






A disk containing no system areas need not be formatted by CPFMTXA. The 
only thing really needed is the volume label. That said, yes, you can 
format only cylinder 0. "CPFMTXA dev volser 0 0" will do it.
 
Regards, 
Richard Schuh 
 
 

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On 
Behalf Of Howard Rifkind
Sent: Monday, September 29, 2008 8:25 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: CPFMTXA VOLUME FORMATTING QUESTION

Hello all,
 
I have a new DASD address which has to be added to z/VM 5.3 which was 
previously formatted with a z/OS format.
 
I didn't do a CPFMTXA format.
 
I attached the volume to system and DDR'ed a few minidisks over to the new 
volume.
 
So, cylinder 0 of the new volume is not in CP format.  The copied 
minidisks are O.K and I would hate to do the copies again.
 
Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire 
volume as PERM without loosing the copied minidisks?
 
Thanks.
 



_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.






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. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercept

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Jim Bohnsack]

I haven't tried it, but I would expect that CPFMTXA LABEL or ALLOCATE 
would fail if the volume or at least cyl 0 had not been formatted with 
CPFMTXA.  One important reason to use ICKDSF CPVOL or CPFMTXA on a 
volume in a mixed, i.e. OS and VM environment is that CPFMTXA or CPVOL 
will leave the OS space available label (can't remember what the number 
of it is) showing that there is NO available space on the volume.  You 
don't want an OS system looking around for dasd space and finding an 
entire volume that's available. 


Jim

Scott Rohling wrote:

--=_Part_42545_33067937.1222703114149
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

A CPFMTXA LABEL should do it for you..  Just label the volume appropriately
--

And - Issue a CPFMTXA ALLOCATE to see what the current allocation is - and
then get out of there if it's allocated as PERM (as I'd expect)..

Scott Rohling

On Mon, Sep 29, 2008 at 9:24 AM, Howard Rifkind <[EMAIL PROTECTED]>wrote:

  

 Hello all,

I have a new DASD address which has to be added to z/VM 5.3 which was
previously formatted with a z/OS format.

I didn't do a CPFMTXA format.

I attached the volume to system and DDR'ed a few minidisks over to the new
volume.

So, cylinder 0 of the new volume is not in CP format.  The copied minidisks
are O.K and I would hate to do the copies again.

Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire
volume as PERM without loosing the copied minidisks?

Thanks.




_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.




--=_Part_42545_33067937.1222703114149
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

A CPFMTXA LABEL should do it for you..  Just label the volume appropriately 
--And - Issue a CPFMTXA ALLOCATE to see what the current allocation is - and then get out of there if 
it's allocated as PERM (as I'd expect)..
Scott RohlingOn Mon, Sep 29, 2008 at 9:24 AM, Howard Rifkind [EMAIL PROTECTED]> wrote:




Hello all,
 
I have a new DASD address which has to be added to z/VM 5.3 which was previously 
formatted with a z/OS format.
 
I didn't do a CPFMTXA format.
 
I attached the volume to system and DDR'ed a few minidisks over to the new 
volume.
 
So, cylinder 0 of the new volume is not in CP format.  The copied minidisks 
are O.K and I would hate to do the copies again.
 
Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire volume 
as PERM without loosing the copied minidisks?
 
Thanks.
 _
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.



--=_Part_42545_33067937.1222703114149--

  


--
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
[EMAIL PROTECTED]

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Scott Rohling]

A CPFMTXA LABEL should do it for you..  Just label the volume appropriately
--

And - Issue a CPFMTXA ALLOCATE to see what the current allocation is - and
then get out of there if it's allocated as PERM (as I'd expect)..

Scott Rohling

On Mon, Sep 29, 2008 at 9:24 AM, Howard Rifkind <[EMAIL PROTECTED]>wrote:

>  Hello all,
>
> I have a new DASD address which has to be added to z/VM 5.3 which was
> previously formatted with a z/OS format.
>
> I didn't do a CPFMTXA format.
>
> I attached the volume to system and DDR'ed a few minidisks over to the new
> volume.
>
> So, cylinder 0 of the new volume is not in CP format.  The copied minidisks
> are O.K and I would hate to do the copies again.
>
> Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire
> volume as PERM without loosing the copied minidisks?
>
> Thanks.
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Schuh, Richard]

A disk containing no system areas need not be formatted by CPFMTXA. The
only thing really needed is the volume label. That said, yes, you can
format only cylinder 0. "CPFMTXA dev volser 0 0" will do it.
 

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind
Sent: Monday, September 29, 2008 8:25 AM
To: IBMVM@LISTSERV.UARK.EDU
    Subject: CPFMTXA VOLUME FORMATTING QUESTION


Hello all,
 
I have a new DASD address which has to be added to z/VM 5.3
which was previously formatted with a z/OS format.
 
I didn't do a CPFMTXA format.
 
I attached the volume to system and DDR'ed a few minidisks over
to the new volume.
 
So, cylinder 0 of the new volume is not in CP format.  The
copied minidisks are O.K and I would hate to do the copies again.
 
Is there anyway to CPFMTXA just cylinder 0 and then allocate the
entire volume as PERM without loosing the copied minidisks?
 
Thanks.
 



_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Jim Bohnsack]

Look at HELP ICKDFS, CKD COMMANDS, CPVOL.  You'll use the command CPVOL 
FORMAT UNIT(cuu) VERIFY(serial) RANGE(0,0) VOLID(serial)


It will default to PERM from cyl 0 to end of volume.

CPFMTXA is just ICKDSF dummied down. Wish they had never introduced the 
command.


Jim

Howard Rifkind wrote:
This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.


--=__Part143DB127.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello all,=0D=0A=20=0D=0AI have a new DASD address which has to be added to=
 z/VM 5.3 which was previously formatted with a z/OS format.=0D=0A=20=0D=0A=
I didn't do a CPFMTXA format.=0D=0A=20=0D=0AI attached the volume to system=
 and DDR'ed a few minidisks over to the new volume.=0D=0A=20=0D=0ASo, cylin=
der 0 of the new volume is not in CP format.  The copied minidisks are O.K =
and I would hate to do the copies again.=0D=0A=20=0D=0AIs there anyway to C=
PFMTXA just cylinder 0 and then allocate the entire volume as PERM without =
loosing the copied minidisks=3F=0D=0A=20=0D=0AThanks.=0D=0A=20=0D=0A___=
__=0D=0ALEGAL NOTICE=0D=0AUnless expressly stated otherwise, this messa=
ge is confidential=0D=0Aand may be privileged. It is intended for the addre=
ssee(s) only.=0D=0AAccess to this E-mail by anyone else is unauthorized.=0D=
=0AIf you are not an addressee, any disclosure or copying of the=0D=0Aconte=
nts of this E-mail or any action taken (or not taken) in=0D=0Areliance on i=
t is unauthorized and may be unlawful. If you are not an=0D=0Aaddressee, pl=
ease inform the sender immediately, then delete this=0D=0Amessage and empty=
 from your trash.=0D=0A
--=__Part143DB127.0__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

=0D=0A=0D=0A=
=0D=0A=0D=0A<=
DIV>Hello all,=0D=0A =0D=0AI have a new DASD add=
ress which has to be added to z/VM 5.3 which was previously formatted with =
a z/OS format.=0D=0A =0D=0AI didn't do a CPFMTXA=
 format.=0D=0A =0D=0AI attached the volume to sy=
stem and DDR'ed a few minidisks over to the new volume.=0D=0A&nb=
sp;=0D=0ASo, cylinder 0 of the new volume is not in CP format.&n=
bsp; The copied minidisks are O.K and I would hate to do the copies again.<=
/DIV>=0D=0A =0D=0AIs there anyway to CPFMTXA just cyli=
nder 0 and then allocate the entire volume as PERM without loosing the copi=
ed minidisks=3F=0D=0A =0D=0AThanks.=0D=0A<=
DIV> _=0D=0ALEGAL NOTICE=0D=0AUnless express=
ly stated otherwise, this message is confiden=
tial=0D=0Aand may be privileged. It is in=
tended for the addressee(s) only.=0D=0AAccess =
to this E-mail by anyone else is unautho=
rized.=0D=0AIf you are not an addressee, =
any disclosure or copying of the=0D=0Acontents=
 of this E-mail or any action taken =
;(or not taken) in=0D=0Areliance on it is=
 unauthorized and may be unlawful. If yo=
u are not an=0D=0Aaddressee, please inform&nbs=
p;the sender immediately, then delete this=0D=0A=
message and empty from your trash.=0D=0A<=
/tr>=0D=0A
--=__Part143DB127.0__=--

  


--
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
[EMAIL PROTECTED]

Re: CPFMTXA VOLUME FORMATTING QUESTION

[Aria Bamdad]

When you use CPFMTXA command, you can specify the from/to cylinder
for your format command.  Specify cyl 0 and then properly allocate the
device as PERM.

As a general procedure, I do not attach any new device to my system
before I CPFMTXA the complete volume.

CPFMTXA VOLUME FORMATTING QUESTION

[Howard Rifkind]

Hello all,
 
I have a new DASD address which has to be added to z/VM 5.3 which was 
previously formatted with a z/OS format.
 
I didn't do a CPFMTXA format.
 
I attached the volume to system and DDR'ed a few minidisks over to the new 
volume.
 
So, cylinder 0 of the new volume is not in CP format.  The copied minidisks are 
O.K and I would hate to do the copies again.
 
Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire volume 
as PERM without loosing the copied minidisks?
 
Thanks.
 
_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.