Date:         Wed, 30 May 2012 12:14:54 -0400
Reply-To:     Bolotin Yevgeniy <YBolotin@SCHOOLS.NYC.GOV>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Bolotin Yevgeniy <YBolotin@SCHOOLS.NYC.GOV>
Subject:      SAS window resizes on proc optsave/optload
In-Reply-To:  A<CAGFkhF9uY6cEq+J0Rt5+iaZ5UvMs=j_Y8mp_VrF3vjCn5YSa_g@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"

My utility macros save all the options, change some of them, do whatever
needs doing, and then re-load the originals (code is included below)

However, a strange thing happens

If I invoke the utility macro from another macro*, then this happens:
When optSave is hit, the SAS window switches from Maximized to Normal
When OptLoad is hit, the SAS window is switched from Normal back to
Maximized
* i.e. I invoke macro A, macro A invokes macro B, macro B invokes
optSave

If I invoke the utility macro from the enhanced editor*, this happens:
When optSave is hit, the SAS window switches from Maximized to Normal
When OptLoad is hit, nothing happens and the SAS window remains normal -
I have to manually re-maximize it
* i.e. I invoke macro B, macro B invokes optSave

If the optsave/optload code is taken out (or &embedded is set to 1), the
window remains maximized throughout.


Any idea why this would be so, or how to make it stop resizing the
window?


Environment:
        Enhanced editor, interactive mode, SAS 9.2 on WinXP 32bit



Code:

        %if &embedded ^= 1 %then %do;
                *save options;
                Proc optSave out=_options;
                Run ;

                option nomprint nomlogic nosymbolgen; ; %* reduce log
spam with utility macros;
        %end;

        (macro code here)

        %if &embedded ^= 1 %then %do;
                *load options;
                Proc optLoad data=_options;
                Run ;
        %end;


Options that are likely to be different from the default: (before macro
is invoked)

OPTNAME OPTVALUE
-----------------------
ERRORCHECK      NORMAL
MAUTOLOCDISPLAY 0
MAUTOSOURCE     1
MCOMPILE        1
MCOMPILENOTE    NONE
MERGENOBY       ERROR
MERROR  1
MINDELIMITER
MINOPERATOR     0
MLOGIC  1
MLOGICNEST      1
MPRINT  1
MPRINTNEST      1
MRECALL 1
MREPLACE        1
MSGLEVEL        N
MSTORED 0
SOURCE  1
SOURCE2 1
SYMBOLGEN       1
SYNTAXCHECK     1
XSYNC   1
XWAIT   0
FULLSTIMER      1




Thanks!



-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Hong Yang
Sent: Wednesday, May 30, 2012 11:07 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Ask for helps for working very big DB in SAS

Hi Ben,


Really appreciate your advices!  It is quite encouraging to know that
this
DB is still manageable to work with usual SAS. In terms of speeding
things
up, since I am pretty new to these, to make sure I understand you
correctly, I summarized your suggestions as follows:


Work directly on SAS datasets, instead of DB. To do so, use this
"sqldump"
to export the DB in to SAS. For the SAS storage options, I am not quite
sure I get the points. But I will check the Alan Churchill posts for it.
It
seems to me that I may still be able to increase the speed without
changing
my RAM or CPU, but re-arrange the drive in a special way may increase
the
performance.  Am I right?


Many thanks indeed for the feedback,


Hong


On Wed, May 30, 2012 at 12:25 AM, Ben Powell <bpowell555@gmail.com>
wrote:

> Hi Hong,
>
> First off 400gb is not huge. The first commercial terabyte db appeared
> many years ago so
> you're by no means in uncharted territory. Look up the history of
Teradata.
>
> Second, there are many different instances of MySQL, different
versions,
> formats and
> platforms. If you're *not* using innodb then the database files can be
> transferred between
> machines without modification and you'll probably find they zip to one
> tenth of the
> uncompressed filesize. Still a huge db?
>
> Since updates are quarterly I would export to SAS. Assuming you have a
> modicum of
> flexibility on your hardware you'll be able to get analytics running
on
> SAS faster than on a
> pure db.
>
> The simplest way to get the data out is an sqldump. This produces SQL
DDL
> scripts that
> SAS can read with perhaps some small syntax adjustments. Once your
import
> script is
> refined you can reuse it each quarter. Sqldump will be one of the
backup
> options on the
> db.
>
> Before thinking about indexes etc, which will make a massive (think
100
> times faster)
> difference, first consider your SAS data storage options. Your budget
here
> will determine
> the final speed avaiable. Search for Alan Churchill's posts on PCIe
drives
> for an idea of the
> top end. Or otherwise figure on a striped hard drive array with a
proven
> fast performance.
> You won't face any memory or CPU issues on your machine so make sure
the
> storage is up
> to scratch.
>
> Once you've done all this come back with specific optimization queries
on
> particular
> datasets where you will have many options,
>
> Regards
>