Date:         Thu, 13 Aug 2009 09:05:42 -0700
Reply-To:     "Terjeson, Mark" <Mterjeson@RUSSELL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
Comments:     To: Dirk Van Krunckelsven <dirk.vk@GMAIL.COM>
From:         "Terjeson, Mark" <Mterjeson@RUSSELL.COM>
Subject:      Re: A question on Call execute
Content-Type: text/plain; charset="us-ascii"

Hi Dirk,

re: You're not alone.  :o)

We have experienced the same thing over the years.

I've used CALL EXECUTE for years when the need
arises and it works well with the one exception
you found.  I too have found that at about 2000+
not only the log can get a little wacky but other
behaviors also start misbehaving.  Every time I
have encountered that, reducing the lines submitted
always falls back into the "working perfectly" realm.

The reason I say "about 2000+" is that I have tested
this quite a bit and the criteria seems to be more
related to a buffer size than an actual line count.
I was able to reproduce the incursion of problems
by reducing the linecount but increasing the volume
of text count, and the inverse of increasing the
linecount and reducing the bytecount per line. (and
I was able to dramatically increase the number of
lines when using shorter line lengths, and vice-verse.
i.e. The problem does not seem to stem from a specific

line count but rather a specific volume of overall bytes.
With fairly typical average line lengths of coding the
line count you will incur goofyness is usually just
over the 2,000+ linecount mark.



Hope this is helpful.


Mark Terjeson
Investment Business Intelligence
Investment Management & Research
Russell Investments
253-439-2367


Russell
Global Leaders in Multi-Manager Investing






                Date:         Thu, 13 Aug 2009 11:41:12 -0400
                Reply-To:     Dirk Van Krunckelsven <dirk.vk@GMAIL.COM>
                Sender:       "SAS(r) Discussion"
<SAS-L@LISTSERV.UGA.EDU>
                From:         Dirk Van Krunckelsven <dirk.vk@GMAIL.COM>
                Subject:      Re: A question on Call execute
</cgi-bin/wa?A2=ind0908b&L=sas-l&D=0&P=42126> 

                Thanks Roland,


                That's what I was suspecting as well... Anyone any clue
as to what exactly
                the limit is?


                There's not just the yukky log, there's also an error at
some point, which
                is odd, because it works nicely on the other rows for
the dataset I have.
                It even errors on a row that worked earlier that has the
same variable,
                format combination that is relevant to this little sql
thing I am doing
                here.


                Oddly enough, after the error, the log printout of the
call execute
                generated code is back to being "nice".


                I seem to be obliged to split my dataset and go through
the call execute
                code a couple of times. It's uggly: retrieving Nobs from
the controller
                and then read in the controler using firstobs and obs,
and creating an
                adjusted equivqlent of _N_'s for counting where I am...
but seems to work.


                Very strange because earlier, for the same thing I
create a humongous proc
                sql with cases for various things on an even bigger
dataset and that works
                nicely... Well...


                Dirk

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________