Wrong Rob: the filename of the RESERVED disks dos not matter at all
(maybe chuckie didn't, but I tried).  FORMAT does take time, and in
some cases (I forgot which) I really wanted that GENERATE didn't
format, so I had to do the RESERVE manually too.  At the end all our
SFS servers had NOFORMAT in their DMSPARMS file: FILEPOOL MINIDISK
doesn't use the (NO)FORMAT parameter from the DMSPARMS file anyway.

Besides FLASHCOPY, there is also DFSMS COPY to quickly format a
minidisk.  Drawback: unless it has changed, the free-of-charge DFSMS
feature is not pre-installed, what is to be regretted, it is so fast.
DATAMOVE can and will use it to copy CMS formatted minidisks, but by
default DATAMOVE dosen't find it.  You'd issue DIRM DATAMOVE CMS
VMLINK SMSMASTR 1B5

Futhermore, when installing a new release, the new VMSERVx users were
never used at all.  Most SFS servers were generated in the VM/ESA 1.0
or 1.1 time; we just gave these servers a new CMS release to live
with.  Migration of SFS couldn't be easier.

2008/7/25 Rob van der Heij <[EMAIL PROTECTED]>:
> On Fri, Jul 25, 2008 at 10:01 PM, Alan Altmark <[EMAIL PROTECTED]> wrote:
>
>> If it isn't easy, I don't think defining SFS filepools is particularly
>> difficult, either, particularly if you use an existing filepool as a
>> model.  It used to be tedious to format new volumes, but these days you
>> just FLASHCOPY a freshly formatted and RESERVEd volume onto a new
>> minidisk.
>
> Chucky! Get him...  he's recommending things he never tried!
> The file name of the reserved file must match the specification of the
> pooldef file, so unless you have have a stock supply of reserved
> volumes with different names, it is not practical. But then, the
> RESERVE does not take too much time. And most likely you forget to
> change the startup parameter so FILESERV GENERATE will format and
> reserve them for you anway.
>
> The easy part these days is that you don't have to worry about
> placement of various disks on different HDAs, since I believe with
> modern DASD subsystems we don't anticipate a failure of a single
> logical volume.
> -Rob
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to