Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-04 Thread Ray Mansell

I looked, and I still have my update to DMSFOR. All it needs is rework
to accommodate the intervening quarter-century's worth of changes to the
source :-)

On 2/3/2015 23:19, Alan Altmark wrote:

Hence my comment about revisiting DMSFOR and DMSAUD.   So instead of
trying to modify the disk such that is is large when subsequently
accessed, I went the route of tricking the RECOMP code.  But I still
believe that the allocation map was never intended to physically move, but
switches locations along with the DIRECTOR file each time the DOP is
flopped.

But it's going to take someone with more patience than I have to perform
more experiments.   I would first write several files to the disk, THEN
expand it, THEN fill the disk.  My intuition is telling me that the newly
RECOMPed allocation map will gladly overlay those first files and create a
mess.

But as I say, some more experiments are needed.  Or Ray's code.  :-)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Alan Altmark
On Tuesday, 02/03/2015 at 06:25 EST, Rick Troth
ri...@velocitysoftware.com wrote:
 On 02/02/2015 07:19 PM, Alan Altmark wrote:
  The protection is in place because of the allocation map.  Unlike
other
  files on the disk, it is in a fixed location since it is written
during
  FORMAT and its size never changes, as that size is based on the size
of
  the disk.  But if you add more cylinders, you add more blocks.  And as
you
  do that, the allocation map has to grow.  But it can't grow.  It's
  surrounded by other data.

 Am not quite following since you changed ADTMCYL, Mike calls it
 malleable, and Ray once had a mod for.

Hence my comment about revisiting DMSFOR and DMSAUD.   So instead of
trying to modify the disk such that is is large when subsequently
accessed, I went the route of tricking the RECOMP code.  But I still
believe that the allocation map was never intended to physically move, but
switches locations along with the DIRECTOR file each time the DOP is
flopped.

But it's going to take someone with more patience than I have to perform
more experiments.   I would first write several files to the disk, THEN
expand it, THEN fill the disk.  My intuition is telling me that the newly
RECOMPed allocation map will gladly overlay those first files and create a
mess.

But as I say, some more experiments are needed.  Or Ray's code.  :-)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Vitale, Joseph
That would be an excellent mod.  IBM should incorporate it, upgrade CMS.


Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ray 
Mansell
Sent: Tuesday, February 03, 2015 10:09 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

Back in those same mid-80s I added code to the FORMAT command to provide an 
'EXTEND' option. You could create a new, larger minidisk, the first cylinders 
of which were a replica of the old one. Then you could simply FORMAT the new 
minidisk, specifying the EXTEND option, and it would magically grow in size to 
occupy all of the new space, with all of the original files intact.

Now, I wonder where I stashed that code...

Ray

On 2/2/2015 19:19, Alan Altmark wrote:
 On Monday, 02/02/2015 at 05:55 EST, Rick Troth 
 ri...@velocitysoftware.com wrote:
 Evidently, FORMAT makes a note of the number of cylinders it block 
 formatted (the low level phase) first time around. Guessing that is 
 the purpose of ADTMCYL. I should have known. Sorry, Joe.

 So you can (RECOMP smaller and you can (RECOMP larger, but no larger 
 than some pre-detected size.
 You can't RECOMP anything larger than the originally formatted size.   You
 can RECOMP lower and back again, but no larger.  And, yes, ADTMCYL 
 holds the number of formatted cylinders..

 The protection is in place because of the allocation map.  Unlike 
 other files on the disk, it is in a fixed location since it is written 
 during FORMAT and its size never changes, as that size is based on the 
 size of the disk.  But if you add more cylinders, you add more blocks.  
 And as you do that, the allocation map has to grow.  But it can't 
 grow.  It's surrounded by other data.

 I have to say, it's kind of fun to lean back in my rocking chair and 
 see my programmer id in FORMAT (DMSFOR) from back in the mid-80s.  :-)

 Alan Altmark

 Senior Managing z/VM and Linux Consultant Lab Services System z 
 Delivery Practice IBM Systems  Technology Group 
 ibm.com/systems/services/labservices
 office: 607.429.3323
 mobile; 607.321.7556
 alan_altm...@us.ibm.com
 IBM Endicott

 --
 For LINUX-390 subscribe / signoff / archive access instructions, send 
 email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit 
 http://wiki.linuxvm.org/



--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Ray Mansell

Back in those same mid-80s I added code to the FORMAT command to provide
an 'EXTEND' option. You could create a new, larger minidisk, the first
cylinders of which were a replica of the old one. Then you could simply
FORMAT the new minidisk, specifying the EXTEND option, and it would
magically grow in size to occupy all of the new space, with all of the
original files intact.

Now, I wonder where I stashed that code...

Ray

On 2/2/2015 19:19, Alan Altmark wrote:

On Monday, 02/02/2015 at 05:55 EST, Rick Troth
ri...@velocitysoftware.com wrote:

Evidently, FORMAT makes a note of the number of cylinders it block
formatted (the low level phase) first time around. Guessing that is
the purpose of ADTMCYL. I should have known. Sorry, Joe.

So you can (RECOMP smaller and you can (RECOMP larger, but no larger
than some pre-detected size.

You can't RECOMP anything larger than the originally formatted size.   You
can RECOMP lower and back again, but no larger.  And, yes, ADTMCYL holds
the number of formatted cylinders..

The protection is in place because of the allocation map.  Unlike other
files on the disk, it is in a fixed location since it is written during
FORMAT and its size never changes, as that size is based on the size of
the disk.  But if you add more cylinders, you add more blocks.  And as you
do that, the allocation map has to grow.  But it can't grow.  It's
surrounded by other data.

I have to say, it's kind of fun to lean back in my rocking chair and see
my programmer id in FORMAT (DMSFOR) from back in the mid-80s.  :-)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Alan Altmark
On Tuesday, 02/03/2015 at 10:33 EST, Vitale, Joseph
joseph.vit...@bnymellon.com wrote:
 That would be an excellent mod.  IBM should incorporate it, upgrade CMS.

I understand, but given that it is something easily worked around, I don't
see it ever being done.

The challenge is to inform the end user when they've strayed from the
Righteous Path.  Maybe ACCESS should tell you when the formatted size of
the disk doesn't match the physical size.  Then the HELP for the message
could nudge you back into the Light.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Michael Harding
Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 02/02/2015 04:19:19
PM:

 From: Alan Altmark/Endicott/IBM@IBMUS
 To: LINUX-390@VM.MARIST.EDU
 Date: 02/02/2015 04:20 PM
 Subject: Re: Expanding  CMS  Mini Disk - DDR or Copyfile? - still
 not expanding
 Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU

 The protection is in place because of the allocation map.  Unlike other
 files on the disk, it is in a fixed location since it is written during
 FORMAT and its size never changes, as that size is based on the size of
 the disk.  But if you add more cylinders, you add more blocks.  And as
you
 do that, the allocation map has to grow.  But it can't grow.  It's
 surrounded by other data.

 I have to say, it's kind of fun to lean back in my rocking chair and see
 my programmer id in FORMAT (DMSFOR) from back in the mid-80s.  :-)

 Alan Altmark

 Senior Managing z/VM and Linux Consultant
 Lab Services System z Delivery Practice
 IBM Systems  Technology Group
 ibm.com/systems/services/labservices
 office: 607.429.3323
 mobile; 607.321.7556
 alan_altm...@us.ibm.com
 IBM Endicott
I have to take exception.
The allocation map like the directory is at heart just another file.
Changed block(s) in the allocation map get re-written in a different
location as part of the safe updating of a minidisk's metadata.  It's size,
too, is at least partly malleable.  Pulling from another of your posts,
allocate and format a 200-cylinder minidisk.  That's big enough for the
allocation map to be larger than one disk block.  It will actually occupy
3: two data and one index block to which the directory points.  Now recomp
the disk to 150 cylinders.  The allocation map will now fit in a single
block and that's all that gets written.  If you later recomp back to 200
cylinders (as you pointed out, that's do-able) the allocation map will grow
back to its original size and its directory entry updated accordingly.


--
Mike Harding
z/VM System Support

/sp

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Alan Altmark
On Tuesday, 02/03/2015 at 01:43 EST, Michael Harding/Oakland/IBM@IBMUS
wrote:
 I have to take exception.

I get that alot, but forgive you.  :-)

 The allocation map like the directory is at heart just another file.
 Changed block(s) in the allocation map get re-written in a different
 location as part of the safe updating of a minidisk's metadata.  It's
size,
 too, is at least partly malleable.  Pulling from another of your posts,
 allocate and format a 200-cylinder minidisk.  That's big enough for the
 allocation map to be larger than one disk block.  It will actually
occupy
 3: two data and one index block to which the directory points.  Now
recomp
 the disk to 150 cylinders.  The allocation map will now fit in a single
 block and that's all that gets written.  If you later recomp back to 200
 cylinders (as you pointed out, that's do-able) the allocation map will
grow
 back to its original size and its directory entry updated accordingly.

I already said that you can recomp the disk back up to its original size
without problems.  Even so, I got curious (ouch!) and went and looked at
DMSFOR and DMSAUD again, and here's what I got to work:

1. Format the additional cylinders using the same block size as the
original.  Do this with a separate  minidisk, as the FORMAT command
requires that you start on cylinder 0.  This disk must be adjacent to the
old disk.  If you don't do this, then CMS will eventually get I/O errors
on the disk.  Not today, but someday.  N.B. A while back I looked at
updating FORMAT to allow you to format arbitrary extents, with or without
a label.

2. DETACH the current minidisk.

3. Change the MDISK definition for the original disk to include the extra
cylinders and rewrite the directory.

4. LINK the disk.  It now has extra cylinders on the end.  If it doesn't,
go to step 2.

5. Change the ADTMCYL field on disk label to reflect the new cylinder
count, making it look like the disk has been RECOMPed.  ADTMCYL is a
fullword located at offset +24 (decimal) into record 3 of cylinder 0 track
0 (the label).

I used DITTO to change it.  A simple pipe with MDISKBLK READ and WRITE
would easily do it, but be careful since MDISKBLK requires the disk to the
ACCESSed.  (Why?  The blocksize is located on the label, too.)

6. FORMAT vaddr fm new_size ( RECOMP

I tested this by using temp disks of different sizes and DDR to copy the
small one to a larger one that I had previously formatted.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-03 Thread Rick Troth
On 02/03/2015 05:45 PM, Alan Altmark wrote:
 1. Format the additional cylinders using the same block size as the
 original.   ...

Which is not needed if the underlying media is FBA.

Since this *is* the Linux/390 discussion, it's fair to explain
CMS FORMAT in Linux terms. It is akin to  'mformat'  (from the
mtools package) in that it combines both low level (blocks,
tracks, cylinders) and high level (filesystem). MS-DOS 'format'
is another which does both, for those unafraid to say voldemort.
Your step #1 there is using it for the low level part.
One could use  'dasdfmt -d ldl'  instead.
Just sayin.


On 02/02/2015 07:19 PM, Alan Altmark wrote:
 You can't RECOMP anything larger than the originally formatted size.   You
 can RECOMP lower and back again, but no larger.  And, yes, ADTMCYL holds
 the number of formatted cylinders..

Which you changed in your step #5 (in your latter ouch note).


 The protection is in place because of the allocation map.  Unlike other
 files on the disk, it is in a fixed location since it is written during
 FORMAT and its size never changes, as that size is based on the size of
 the disk.  But if you add more cylinders, you add more blocks.  And as you
 do that, the allocation map has to grow.  But it can't grow.  It's
 surrounded by other data.

Am not quite following since you changed ADTMCYL, Mike calls it
malleable, and Ray once had a mod for.

SMOP


 I have to say, it's kind of fun to lean back in my rocking chair and see
 my programmer id in FORMAT (DMSFOR) from back in the mid-80s.

RIP


On 02/03/2015 10:08 AM, Ray Mansell wrote:
 Back in those same mid-80s I added code to the FORMAT command to provide
 an 'EXTEND' option. You could create a new, larger minidisk, the first
 cylinders of which were a replica of the old one. Then you could simply
 FORMAT the new minidisk, specifying the EXTEND option, and it would
 magically grow in size to occupy all of the new space, with all of the
 original files intact.

Various places you could publish that. Various VMers might could make
use of it.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Alan Altmark
On Monday, 02/02/2015 at 10:05 EST, Vitale, Joseph
joseph.vit...@bnymellon.com wrote:
 I tried your approach, the number of cylinders never expanded. What I
did, all
 is on  CKD  IBM 3390-9 disk

 1)  Expanding  mdisk  991 size= 10Cyl.10 free cylinders exist after
this
 mdisk.  Want to expand 991 from 10 to 20 cyl
 2)  Defined another mini disk 992 for 10 Cyl, starting at next free
cylinder
 after 991
 3)  directxa
 4)  logon   CMF  format 992
 5)  logoff as user
 6)  add 10 cylinders to user mdisk 991,  directxa
 7)  logon as user,,   acc 991 B,   format 991 b 20 (recomp Shows
only 10
 cyl:
 format 991 b 20 (recomp
 LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT
BLK TOTAL
 XEC991 991  B   R/W10 3390 4096   79   1794-99  6
1800

 8)  Tried this a few different ways, same result. MDISK not expanded
from 10 to
 20 cyl

There is only one way to expand a CMS minidisk:
1.  Create new minidisk that is larger than the old one
2.  CMS FORMAT the new disk  (without the RECOMP option!)
3.  Copy the CMS files from the old disk to the new disk
4 . Delete the old minidisk
5.  Rename the new minidisk to the old one.

How you do those things can vary, but they all must be done.

You cannot just add cylinders to an existing minidisk.   DEDICATED dasd
volumes can be dynamically resized via the storage controller admin
functions, but CMS won't recognize or use the additional space.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Alan Altmark
On Monday, 02/02/2015 at 05:55 EST, Rick Troth
ri...@velocitysoftware.com wrote:
 Evidently, FORMAT makes a note of the number of cylinders it block
 formatted (the low level phase) first time around. Guessing that is
 the purpose of ADTMCYL. I should have known. Sorry, Joe.

 So you can (RECOMP smaller and you can (RECOMP larger, but no larger
 than some pre-detected size.

You can't RECOMP anything larger than the originally formatted size.   You
can RECOMP lower and back again, but no larger.  And, yes, ADTMCYL holds
the number of formatted cylinders..

The protection is in place because of the allocation map.  Unlike other
files on the disk, it is in a fixed location since it is written during
FORMAT and its size never changes, as that size is based on the size of
the disk.  But if you add more cylinders, you add more blocks.  And as you
do that, the allocation map has to grow.  But it can't grow.  It's
surrounded by other data.

I have to say, it's kind of fun to lean back in my rocking chair and see
my programmer id in FORMAT (DMSFOR) from back in the mid-80s.  :-)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems  Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Vitale, Joseph
I followed your procedure,  still shows  10 Cylinders.  Here is what I did:

B e f o r e  mdisk change:
 q disk
LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT  BLK TOTAL
MNT191 191  A   R/W10 3390 4096   74856-48944   1800
D991   991  C   R/W10 3390 40960  7-00   1793   1800
D992   992  D   R/W10 3390 40960  7-00   1793   1800
MNT190 190  S   R/O   207 3390 4096  694  18493-50  18767  37260
MNT19E 19E  Y/S R/O   500 3390 4096 1136  30522-34  59478  9

rel d (det
DASD 0992 DETACHED

rel c
det 991
DASD 0991 DETACHED

 User Direct change  DIrectxa by MAINT620 
MDISK 991 3390 746   20  M01W02  MR READ WRITEMULTIPLE   - New
*MDISK 991 3390 746   10  M01W02  MR READ WRITEMULTIPLE  - Old
*MDISK 992 3390 756   10  M01W02  MR READ WRITEMULTIPLE  - Old

A f t e r   MDISK change:

link xecck6d 991 991 mr

q v 991
DASD 0991 3390 M01W02 R/W 20 CYL ON DASD  7F05 SUBCHANNEL = 0005

format 991 (recomp
DMSPCL386E Missing operand(s)
Ready(00024); T=0.01/0.01 11:26:51

format 991 20 (recomp
DMSPCL389E Invalid filemode: 20
Ready(00024); T=0.01/0.01 11:27:15

format 991 c 20 (recomp
DMSFOR069E Filemode C(991) not accessed
Ready(00036); T=0.01/0.01 11:27:34

acc 991 c
Ready; T=0.01/0.01 11:27:45

format 991 c 20 (recomp
LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT  BLK TOTAL
D991   991  C   R/W10 3390 40960  7-00   1793   1800
Ready; T=0.01/0.01 11:27:59

q v 991
DASD 0991 3390 M01W02 R/W 20 CYL ON DASD  7F05 SUBCHANNEL = 0005
Ready; T=0.01/0.01 11:28:13

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rick Troth
Sent: Monday, February 02, 2015 10:39 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

On 02/02/2015 09:42 AM, Vitale, Joseph wrote:
 I tried your approach, the number of cylinders never expanded. What I 
 did, all is on  CKD  IBM 3390-9 disk

Sorry for the confusion. I think they way I wrote that was a little hard to 
follow.

To reduce some of your effort, just DETACH and LINK rather than LOGOFF and 
LOGON.

Seeing you're using DIRECTXA, here is a recipe for in-place expand:

  * define 10 cyls after the existing minidisk, call it 992
  * DIRECTXA that update so CP knows about it
  * link to the 992 minidisk and FORMAT it (to get it blocked, in case
it is not already)
  * detach the 992
  * redefine the 991 as 20 cyls, removing the temporary 992
now 991 occupies all 20 cyls but starts at same as it did originally
  * DIRECTXA that so it's online and CP knows
  * release the 991 and detach it
  * re-link the 991 and access it
  * Q V 991 to confirm CP is giving you all 20 cyls
  * FORMAT (RECOMP


FORMAT (RECOMP should detect the number of cylinders it gets from CP and give 
you the full 20.

I HAVE NOT tested the above steps, but have tested FORMAT (RECOMP in similar 
change-up.

The only tricky part to expanding a minidisk in place is that the new storage 
must be blocked same as the existing cylinders.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Vitale, Joseph
I appreciate your help, good insight into how this works.

I used a V-DISK to copy from  real mdisk, then   to  newly allocated mdisk.

Joe 

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rick Troth
Sent: Monday, February 02, 2015 5:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

I stand corrected.


On 02/02/2015 03:10 PM, Alan Altmark wrote:
 There is only one way to expand a CMS minidisk:
 1.  Create new minidisk that is larger than the old one 2.  CMS FORMAT 
 the new disk  (without the RECOMP option!) 3.  Copy the CMS files from 
 the old disk to the new disk
...

Evidently, FORMAT makes a note of the number of cylinders it block formatted 
(the low level phase) first time around. Guessing that is the purpose of 
ADTMCYL. I should have known. Sorry, Joe.

So you can (RECOMP smaller and you can (RECOMP larger, but no larger than some 
pre-detected size.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Rick Troth
I stand corrected.


On 02/02/2015 03:10 PM, Alan Altmark wrote:
 There is only one way to expand a CMS minidisk:
 1.  Create new minidisk that is larger than the old one
 2.  CMS FORMAT the new disk  (without the RECOMP option!)
 3.  Copy the CMS files from the old disk to the new disk
...

Evidently, FORMAT makes a note of the number of cylinders it block
formatted (the low level phase) first time around. Guessing that is
the purpose of ADTMCYL. I should have known. Sorry, Joe.

So you can (RECOMP smaller and you can (RECOMP larger, but no larger
than some pre-detected size.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Vitale, Joseph
Thank you Alan!

Joe

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan 
Altmark
Sent: Monday, February 02, 2015 3:11 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

On Monday, 02/02/2015 at 10:05 EST, Vitale, Joseph
joseph.vit...@bnymellon.com wrote:
 I tried your approach, the number of cylinders never expanded. What I
did, all
 is on  CKD  IBM 3390-9 disk

 1)  Expanding  mdisk  991 size= 10Cyl.10 free cylinders exist after
this
 mdisk.  Want to expand 991 from 10 to 20 cyl
 2)  Defined another mini disk 992 for 10 Cyl, starting at next free
cylinder
 after 991
 3)  directxa
 4)  logon   CMF  format 992
 5)  logoff as user
 6)  add 10 cylinders to user mdisk 991,  directxa
 7)  logon as user,,   acc 991 B,   format 991 b 20 (recomp Shows
only 10
 cyl:
 format 991 b 20 (recomp
 LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT
BLK TOTAL
 XEC991 991  B   R/W10 3390 4096   79   1794-99  6
1800

 8)  Tried this a few different ways, same result. MDISK not expanded
from 10 to
 20 cyl

There is only one way to expand a CMS minidisk:
1.  Create new minidisk that is larger than the old one 2.  CMS FORMAT the new 
disk  (without the RECOMP option!) 3.  Copy the CMS files from the old disk to 
the new disk
4 . Delete the old minidisk
5.  Rename the new minidisk to the old one.

How you do those things can vary, but they all must be done.

You cannot just add cylinders to an existing minidisk.   DEDICATED dasd
volumes can be dynamically resized via the storage controller admin functions, 
but CMS won't recognize or use the additional space.

Alan Altmark

Senior Managing z/VM and Linux Consultant Lab Services System z Delivery 
Practice IBM Systems  Technology Group ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Vitale, Joseph
I tried your approach, the number of cylinders never expanded. What I did, all 
is on  CKD  IBM 3390-9 disk

1)  Expanding  mdisk  991 size= 10Cyl.10 free cylinders exist after this 
mdisk.  Want to expand 991 from 10 to 20 cyl
2)  Defined another mini disk 992 for 10 Cyl, starting at next free cylinder 
after 991 
3)  directxa
4)  logon   CMF  format 992
5)  logoff as user
6)  add 10 cylinders to user mdisk 991,  directxa
7)  logon as user,,   acc 991 B,   format 991 b 20 (recomp Shows only 10 
cyl:
format 991 b 20 (recomp
LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT  BLK TOTAL
XEC991 991  B   R/W10 3390 4096   79   1794-99  6   1800

8)  Tried this a few different ways, same result. MDISK not expanded from 10 to 
20 cyl

Thanks

Joseph Vitale
Technology Services Group
Mainframe Operating Systems

Pershing Plaza
95 Christopher Columbus Drive
Floor 14   
Jersey City,  N.J.  07302
Work  201-395-1509
Cell917-903-0102


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rick Troth
Sent: Sunday, February 01, 2015 7:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expanding CMS Mini Disk - DDR or Copyfile?

On 01/31/2015 10:37 AM, Vitale, Joseph wrote:
 Question on expanding a CMS.  Normally I create a new mini disk(larger)  and 
 use COPYFile  Old to New mini disk.  That could leave Cylinder gaps on disk 
 when old mini disk is deleted.

Gaps, true.

But are you wanting to enlarge the minidisk in-place? That requires a gap 
*after* it's present location. So the gap thing cuts both ways.


 Is there a procedure that allows me to back up a mini disk and restore to a 
 new larger mini disk, aside from using  COPYFile?   DDR seems to be a 
 Cylinder to Cylinder backup/restore?

If you backup then restore, you might as well use COPYFILE.
Not clear if you want to avoid COPYFILE or avoid gaps.

To do it in-place, besure the gap following the minidisk gets block formatted 
(ie: low level formatted). Allocate another minidisk there, then CMS FORMAT 
it, then deallocate it, then enlarge the original minidisk adding that space to 
it.

After all that, detach and re-link the minidisk, then FORMAT (RECOMP.

If you're on FBA or EDEV/SAN, there's no need to format the gap. Just enlarge 
the minidisk into it. Then detach, re-link, and RECOMP.

With CKD, CMS FORMAT combines the operation of Linux 'dasdfmt' and 'mkfs'.
With FBA, CMS FORMAT only does the 'mkfs' part. (No 'dasdfmt' equivalent
needed.)
For both types, 'FORMAT (RECOMP' is akin to a 'resize2fs'.
I hope this helps.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile? - still not expanding

2015-02-02 Thread Rick Troth
On 02/02/2015 09:42 AM, Vitale, Joseph wrote:
 I tried your approach, the number of cylinders never expanded. What I did, 
 all is on  CKD  IBM 3390-9 disk

Sorry for the confusion. I think they way I wrote that was a little hard
to follow.

To reduce some of your effort, just DETACH and LINK rather than LOGOFF
and LOGON.

Seeing you're using DIRECTXA, here is a recipe for in-place expand:

  * define 10 cyls after the existing minidisk, call it 992
  * DIRECTXA that update so CP knows about it
  * link to the 992 minidisk and FORMAT it (to get it blocked, in case
it is not already)
  * detach the 992
  * redefine the 991 as 20 cyls, removing the temporary 992
now 991 occupies all 20 cyls but starts at same as it did originally
  * DIRECTXA that so it's online and CP knows
  * release the 991 and detach it
  * re-link the 991 and access it
  * Q V 991 to confirm CP is giving you all 20 cyls
  * FORMAT (RECOMP


FORMAT (RECOMP should detect the number of cylinders it gets from CP and
give you the full 20.

I HAVE NOT tested the above steps, but have tested FORMAT (RECOMP in
similar change-up.

The only tricky part to expanding a minidisk in place is that the new
storage must be blocked same as the existing cylinders.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile?

2015-02-01 Thread Rick Troth
On 01/31/2015 10:37 AM, Vitale, Joseph wrote:
 Question on expanding a CMS.  Normally I create a new mini disk(larger)  and 
 use COPYFile  Old to New mini disk.  That could leave Cylinder gaps on disk 
 when old mini disk is deleted.

Gaps, true.

But are you wanting to enlarge the minidisk in-place? That requires a
gap *after* it's present location. So the gap thing cuts both ways.


 Is there a procedure that allows me to back up a mini disk and restore to a 
 new larger mini disk, aside from using  COPYFile?   DDR seems to be a 
 Cylinder to Cylinder backup/restore?

If you backup then restore, you might as well use COPYFILE.
Not clear if you want to avoid COPYFILE or avoid gaps.

To do it in-place, besure the gap following the minidisk gets block
formatted (ie: low level formatted). Allocate another minidisk there,
then CMS FORMAT it, then deallocate it, then enlarge the original
minidisk adding that space to it.

After all that, detach and re-link the minidisk, then FORMAT (RECOMP.

If you're on FBA or EDEV/SAN, there's no need to format the gap. Just
enlarge the minidisk into it. Then detach, re-link, and RECOMP.

With CKD, CMS FORMAT combines the operation of Linux 'dasdfmt' and 'mkfs'.
With FBA, CMS FORMAT only does the 'mkfs' part. (No 'dasdfmt' equivalent
needed.)
For both types, 'FORMAT (RECOMP' is akin to a 'resize2fs'.
I hope this helps.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com mailto:ri...@velocitysoftware.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Expanding CMS Mini Disk - DDR or Copyfile?

2015-01-31 Thread Vitale, Joseph
Hello,

Question on expanding a CMS.  Normally I create a new mini disk(larger)  and 
use COPYFile  Old to New mini disk.  That could leave Cylinder gaps on disk 
when old mini disk is deleted.

Is there a procedure that allows me to back up a mini disk and restore to a new 
larger mini disk, aside from using  COPYFile?   DDR seems to be a Cylinder to 
Cylinder backup/restore?

Thanks
Joe



The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile?

2015-01-31 Thread Ronald van der Laan
Joe,

If you got DFSMS installed, the DFSMS COPY command followed by a CMS format
recomp, is a very nice and fast option to copy one minidisk to a new fresh
(unformatted) minidisk.
More convinient is of course to use a directory manager...

Ronald van der Laan.


--
Ronald van der Laan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile?

2015-01-31 Thread Pedro Principeza
Joe,

I've seen customers use the COPY operation, on z/OS, adding:

COPYV ALLEXCP

The disks being copied were not CMS, but I guess you may try that.

HTH,
--
Pedro Principeza



From:   Ronald van der Laan nl50...@gmail.com
To: LINUX-390@VM.MARIST.EDU
Date:   31/01/2015 15:16
Subject:Re: Expanding CMS Mini Disk - DDR or Copyfile?
Sent by:Linux on 390 Port LINUX-390@VM.MARIST.EDU



Joe,

If you got DFSMS installed, the DFSMS COPY command followed by a CMS
format
recomp, is a very nice and fast option to copy one minidisk to a new fresh
(unformatted) minidisk.
More convinient is of course to use a directory manager...

Ronald van der Laan.


--
Ronald van der Laan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile?

2015-01-31 Thread Gentry, Steve
With the way you describe your situation, you need to copy the files on the 
existing/current CMS minidisk to a temporary area.  That could be another 
minidisk of equal or larger size or TAPE DUMP the minidisk (if you have some 
kind of tape subsystem available).  Once the COPY or TAPE DUMP is done.  You 
can then redefine the existing area, making it larger and then COPY or TAPE 
LOAD the data back to the new area.  You may want to keep the current create 
dates of the files on the minidisk.  If that's the case, use the OLDDATE option 
parameter when using COPY. TAPE DUMP/TAPE LOAD will automatically keep the 
create date.
Why don't you want gaps?  They don't hurt anything and it just makes more work 
for you, trying to eliminate the gaps, when you want to move things around.
BTW, you are talking about CMS files on a minidisk, correct?  Not a minidisk 
defined for use by Linux or some other non-CMS minidisk.  If so, the COPY or 
TAPE DUMP won't work for this situation.
Steve

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Vitale, 
Joseph
Sent: Saturday, January 31, 2015 10:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Expanding CMS Mini Disk - DDR or Copyfile?

Hello,

Question on expanding a CMS.  Normally I create a new mini disk(larger)  and 
use COPYFile  Old to New mini disk.  That could leave Cylinder gaps on disk 
when old mini disk is deleted.

Is there a procedure that allows me to back up a mini disk and restore to a new 
larger mini disk, aside from using  COPYFile?   DDR seems to be a Cylinder to 
Cylinder backup/restore?

Thanks
Joe



The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Expanding CMS Mini Disk - DDR or Copyfile?

2015-01-31 Thread Edward Gilroy
Dirmaint does this very simply, if you have it

Sent from my iPhone - Expect lots of typos!!!

 On Jan 31, 2015, at 12:56 PM, Gentry, Steve 
 steve.gen...@westernsouthernlife.com wrote:
 
 With the way you describe your situation, you need to copy the files on the 
 existing/current CMS minidisk to a temporary area.  That could be another 
 minidisk of equal or larger size or TAPE DUMP the minidisk (if you have some 
 kind of tape subsystem available).  Once the COPY or TAPE DUMP is done.  You 
 can then redefine the existing area, making it larger and then COPY or TAPE 
 LOAD the data back to the new area.  You may want to keep the current create 
 dates of the files on the minidisk.  If that's the case, use the OLDDATE 
 option parameter when using COPY. TAPE DUMP/TAPE LOAD will automatically keep 
 the create date.
 Why don't you want gaps?  They don't hurt anything and it just makes more 
 work for you, trying to eliminate the gaps, when you want to move things 
 around.
 BTW, you are talking about CMS files on a minidisk, correct?  Not a minidisk 
 defined for use by Linux or some other non-CMS minidisk.  If so, the COPY or 
 TAPE DUMP won't work for this situation.
 Steve
 
 -Original Message-
 From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Vitale, 
 Joseph
 Sent: Saturday, January 31, 2015 10:37 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Expanding CMS Mini Disk - DDR or Copyfile?
 
 Hello,
 
 Question on expanding a CMS.  Normally I create a new mini disk(larger)  and 
 use COPYFile  Old to New mini disk.  That could leave Cylinder gaps on disk 
 when old mini disk is deleted.
 
 Is there a procedure that allows me to back up a mini disk and restore to a 
 new larger mini disk, aside from using  COPYFile?   DDR seems to be a 
 Cylinder to Cylinder backup/restore?
 
 Thanks
 Joe
 
 
 
 The information contained in this e-mail, and any attachment, is confidential 
 and is intended solely for the use of the intended recipient. Access, copying 
 or re-use of the e-mail or any attachment, or any information contained 
 therein, by any other person is not authorized. If you are not the intended 
 recipient please return the e-mail to the sender and delete it from your 
 computer. Although we attempt to sweep e-mail and attachments for viruses, we 
 do not guarantee that either are virus-free and accept no liability for any 
 damage sustained as a result of viruses. 
 
 Please refer to http://disclaimer.bnymellon.com/eu.htm for certain 
 disclosures relating to European legal entities.
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions, send email 
 to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit http://wiki.linuxvm.org/
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/