Date: Wed, 24 May 2000 20:58:11 +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>
Subject: Re: stack overflows using views on MVS
Content-Type: text/plain; charset=us-ascii
Paula ... highly unlikely that any site will consider re-installing the
mainframe OS because a SAS program has this sort of problem.
There are a number of things that can be tried::
* upping the region size for the job
* increasing memsize to say 32M (you use proc options to find what it is
* if a sort is involved (including an SQL join that may need to sort
internally) try increasing the SORT= option. I often use NODYNALLOC as
well which for whatever reason seems to have a positive impact on very
big sorts. Also SORTWKNO=x will allow you to allocate x sort files which
may help here
* reducing the complexity of the view. For example, does the VIEW read 1 or
many datasets, how big is the program data vector etc etc. Does the view
use an extraordinarily large number of IF then else statements?
Paula is right that it is likely to be a resource problem, today I struck it
with a SORT and just bumped SORT= to 1000 which fixed it immediately.
There are no reasons to avoid views on MVS, only reasons to ensure code is
written as efficiently as possible and a realisation that MVS, despite its
grunt, is as resource constrained as any other OS. If you haven't got the
resource, you can't have the resource.
Dean, if you can't get this working post the view. Its obviously doing a mass
of work to get those 828252 observations.
> Stack overflow typically suggests problems with OS, in handling memory for
> example. Maybe reinstallation of OS is first choice.
> Paula D
> "Bross, Dean S" <dean.bross@MAIL.VA.GOV> wrote in message
> > Has anyone had trouble with views running under MVS
> > I got the following message in my log:
> > NOTE: The view WORK.X.VIEW used 412.70 CPU seconds and 4160K.
> > NOTE: Task SASDSVX had 11 stack overflows with a max stack size of 16384
> > a max overflow segment depth of 1. The load module
> > name for this task is SASDSVX.
> > NOTE: The data set WW.A has 828252 observations and 5 variables.
> > NOTE: The DATA statement used 23.73 CPU seconds and 4160K.
> > Does this indicate a serious problem
> > I tried repeating the run, substituting data sets for views,
> > and the results agreed with what I had obtained in this run.
> > Do problems like this suggest views should be avoided under MVS
> > Dean Bross
Don Stanley, B.SC, Dip O.R.S, MNZCS Director, Sysware Consulting Group
Box 634, Wellington, NEW ZEALAND