ADSM-L

Re: Dataset allocation of ADSM for MVS V3

1999-01-29 10:15:06
Subject: Re: Dataset allocation of ADSM for MVS V3
From: Bill Colwell <bcolwell AT DRAPER DOT COM>
Date: Fri, 29 Jan 1999 10:15:06 -0500
In <0A7C0CA16D80D2119B000000832FE2D4773030@X0F0000>, on 01/29/99
   at 01:11 PM, "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT NL> said:

>Hi Bill!
>Last week I created a devclass with devtype=file and a maxcap=2047M. I
>wanted to use this deviceclass for Export processing.
>ADSM allocates this dataset in primary and secondary extends.
>When I started an export, it ran for some time until the dataset was full.
>ADSM issues a B37 abend and deletes the export dataset.
>In my second attempt I pre-allocated the export dataset and started an
>export with that dataset as input (volumename=datasetname). This issued a
>message: "duplicate dataset name" which indicates that ADSM tries to
>re-catalog the dataset while it is already cataloged (of course, I
>pre-allocated it).
>I haven't tested this for normal backups, only for exports and maybe this
>bug is fixed in the version 3 server code. I'm using a 2.1.0.13 server on
>MVS.
>Kindest regards,
>Eric van Loon

>-----Original Message-----
>From: Bill Colwell [mailto:bcolwell AT DRAPER DOT COM]
>Sent: Thursday, January 28, 1999 17:34
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Dataset allocation of ADSM for MVS V3

>It explains all, and you can preallocate the volumes to get exactly the
>size you want.

There aren't any bugs here.  IBM made some changes in the middle of version
2's life.  See the anr2210 readme file.  Find 'pn73862' and 'pn74567' which
is right after the first.  The change made adsm insist on allocating
dev=file files when the function is for export or dbb.  You can still
preallocate files for use as storagepool volumes.  You are correct in saying
that one should not let dfsms release the space from storagepool volumes,
unless you mark them read-only in adsm first.

I do many exports of users who leave the company.  I export them to dev=file
files and then let hsm manage them.  It's working great for me. I also do
incremental dbb to dev=file files for 6 days and then a full to tape on
Sunday.  This too runs very smoothly.

ADSM doesn't like to get any return codes/abends from mvs during dev=file
processing.  It writes upto the maxcapacity value of the devclass and stops
there just before mvs would have given an x37.
I have a special storagegroup for these files, and use 512 meg
files to avoid getting x37.  ADSM will allocate more files until it finishes
the export.  My automate product issues hsm backvol commands hourly on
storagegroup volumes so that the hsm interval migration will move these
files to tape.  All this to get the exports to flow smoothly and quickly
thru the dfsms hierarchy. (My dasd is RVA so it isn't a big waste to have
volumes reserved for this storagegroup.)

The dbb incremental go into the primary pool.  They are sized at 128m, which
adsm allocates in one extent.  I have never had a problem with these.  they
migrate during the normal space management cycle.

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>