Date: Thu, 6 Apr 2000 19:01:20 +1200
Reply-To: Don Stanley <don_stanley@XTRA.CO.NZ>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Don Stanley <don_stanley@XTRA.CO.NZ>
Organization: Xtra
Subject: Re: WARNING MVS-- PROSMS StopX37 Product and SAS
Content-Type: text/plain; charset=us-ascii
I think you mis-interpretated what I was saying here!
There is no problem with StopX37. I never said that and I don't believe I implied
it.
There is a problem with SAS libraries that have their space extended into
multi-volume by StopX37. It is in fact a very important and potentially critical
problem, you cannot copy these libraries up with system utilities.
It is well known that SAS and multi-volume datasets don't talk to system utilities.
My post was intended to warn of a situation that we may have no control over,
either because StopX37 has been implemented without consideration of EXCP access,
or because we as users and developers were unaware of its abilities. After all, it
is one of those magic products that we don't ever see and rarely hear about -- ie
it works as intended for system software -- until it does its stuff on something we
really don't want it to.
Theo DP has supplied an interesting post in which he says you can filter StopX37
from EXCP access libraries. Our storage guys aren't aware of this, or alternatively
they aren't aware that SAS uses EXCP. I'll be letting them know tomorrow, as its a
much better filter than the dataset name based one we put in place yesterday.
Don
Ambat Ravi Nair wrote:
> this is not a problem - SAS accesses datasets using EXCP.
> it is clearly stated in StopX37/II manual it cannot guarantee integrity of data
> that is being accessed by EXCP (as above) or NOTE/POINT logic.
>
> i believe SAS v8 has a solution to this issue.
>
> - ravi.
>
> Don Stanley wrote:
>
> > Be wary, this clever little product can cause problems for your SAS
> > libraries. What the product does is sit between MVS and your programs
> > requests for more space. If MVS would have rejected a request for space,
> > StopX37 happily bypasses that and gives it to you. Invariably, the way
> > it does so is by making your library multi-volume.
> >
> > This means a single volume SAS library, requesting another extent, and
> > not enough space to get that extent on the volume, can satisfy the
> > request by making the library multi-volume and giving you the extent on
> > another volume. Great. Except that at 6.12 SAS multi-volume datasets
> > cannot be successfully backed up by HSM , nor can they be successfully
> > manipulated by tools such as ICEGENER. Also, if the library becomes
> > multi-volume on the fly using StopX37, the job is liable to fail with an
> > S318 error.
> >
> > If you get an S318, its very likely that StopX37 made it multi-volume.
> > To check this, just view the JESLOG. Any SMSxxxxx messages are from
> > StopX37. SAS attempts to maintain integrity by abending S318, but our
> > experience has been that if ops just restart the job, the multi-volume
> > library now exists and SAS uses it. No abend will occur, the
> > multi-volume library will be perfectly usable, but any attempt to backup
> > or copy the file outside of SAS tools will fail, despite most likely
> > returning a zero return code so you don't realise a problem exists. The
> > system tool will have copied only the portion of the dataset on the
> > first volume. Better hope you don't need the backups.
> >
> > We struck this problem this week, and to fix it I've had to schedule a
> > change to rename the file, create a new one with more space on one pack,
> > then PROC COPY the file back and delete the multi-volume one.
> >
> > StopX37 is really useful (and confusing, you can find files with many
> > extents, i've hit over 60 and it seems weird when we all know you can
> > only have 16 -- but because it goes multi-volume you can get 16 on each
> > pack in the multi-volume libraries). But for SAS libraries, I've suggest
> > you get your site administrators to exclude them from StopX37 processing
> > at 6.12 if backups or use of non-SAS utilities is important. I
> > understand V8 may have got around this issue.
> >
> > Don
> > --
> > Don Stanley, B.SC, Dip O.R.S, MNZCS Director, Sysware Consulting
> > Group
> > Box 634, Wellington, NEW ZEALAND
> >
> > http://www.sysware.co.nz
> > EMAIL:: don_stanley@xtra.co.nz
> > http://www.geocities.com/don_stanley_nz/don_home.htm
> > Genealogy:: http://www.geocities.com/don_stanley_nz/family.htm
--
Don Stanley, B.SC, Dip O.R.S, MNZCS Director, Sysware Consulting Group
Box 634, Wellington, NEW ZEALAND
http://www.sysware.co.nz
EMAIL:: don_stanley@xtra.co.nz
http://www.geocities.com/don_stanley_nz/don_home.htm
Genealogy:: http://www.geocities.com/don_stanley_nz/family.htm
| 
