Date:         Wed, 5 Feb 2003 22:02:25 -0500
Reply-To:     "Karl K." <karlstudboy@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Karl K." <karlstudboy@HOTMAIL.COM>
Subject:      Re: Fw: SAS Tracking Number us5815303

In re Proc Optsave/Optload vs. dictionary.options--
Kevin wrote:
> I don't know all of the details, but based on a reply that I just received
> from SAS tech support, it appears that these PROCs only deal with options
> for which values can be changed during a SAS session, rather than only at
> initialization time from a config file or the command line.  Seems like it
> would be nice if optsave would save ALL options, then optload would only
> restore the subset that can be set during a SAS session.

Peter wrote:
> about those 100 options....
> mostly, I would guess these are "invocation-only" options

Of course, you called it right, Peter.  I'm probably being guilty of a
"foolish consistency" (the hobgoblin of small minds) between optsave/optload
and dictionary.options.  Might there be a scenario, though, where you would
want to save ALL the options from a session, and then restart SAS later,
restoring all those same options with a single command line parameter?  The
saving part is easily accomplished with:

   create lib.whatever as select * from dictionary.options;

but there's no analog (right, Kevin?) to proc optload *at invocation* to
restore all those options.  I can't think of such a scenario myself, but you
guys know about a million times more SAS than me.

In re running SAS on multiple monitors--
Kevin wrote:
>Yes, I understand exactly what you mean by all of the above.  All of these
>same reasons are why I would like to use options NOAWS under Windows, but
>unfortunately that isn't supported, and it doesn't work properly if you try
>it.

Peter wrote:
>About that double monitor scenario: what response have
>you had from sas customer support?
>SI like to have the win-compliant logo.
> I'm surprised that there are so many gotchas if SAS complies.

I might have come across a little too strongly.  A newbie has no business
crying "non-compliance" when what I mean is "I wish SAS worked like this. .
.".  The only real incompatibility I've been able to replicate consistently
concerns fast user switching.  When SAS is open spanning 2 monitors, if you
fast-switch to another user, then return to the original SAS session, SAS
forgets about the second monitor.  Exit and restart puts everything back to
normal, but that kind of defeats the purpose of fast user switching.  I
confess, I have not reported this to SI.  (SAS is not alone in choking on
fast user switching, btw--Symantec acknowledges that WinFax, for example,
pretty much dies in this situation.)

In all fairness, my other complaints may be more idiosyncratic to how I
work, rather than non-compliance with the windows standard.  My only point
was that certain other apps let you spread out over 2 monitors
"politely"--tucking toolbars and peel-off menus and child windows into
unused desktop real estate however you like, occupying only the area they
need.  A somewhat trivial example is the slideshow view in PowerPoint.  When
you crank up a slide show of the active presentation, you can set PowerPoint
to show you the normal (editable) view on one monitor and the slide show,
full-screen, on the second monitor.  When you exit the slide show, the
screen real estate it occupied is automatically restored, and whatever you
had on the 2nd monitor redisplays.  The SAS AWS sort of hogs the entire
rectangular area.  Even if there's nothing currently displayed (in the
output window, for example), there it is, taking up space.

OK, 'nuff said.  Thanks to the group for its patience in tolerating my
whining.

Karl