Hi SAS-Lers,

I am reviewing the following paper.

New advantages of EG from  http://www.nesug.org/Proceedings/nesug08/ph/ph12.pdf

  1. Enterprise Guide generates better and more reliable code than
programmers
     see SIMPLE JOIN DONE USING EG QUERY AND FILTER AND HAND
CODED
  2. Enterprise Guide enforces a standard programming
style
     see HOW IS A SIMPLE JOIN DONE USING EG QUERY AND FILTER COMPARE
TO HAND CODING

I will update my tecnical comparison document  on my site later. I
have a lot to add.

HOW IS A SIMPLE JOIN DONE USING EG QUERY AND FILTER COMPARE TO HAND
CODING
/* CREATE TWO TABLES TO JOIN
*/
data tstndx(index=(pid/unique study stycrt=(study
crt)));
  do study=1 to
30;
     do crt=1 to
10;
          do id=1 to
10000;
              pid=cats(put(study,z2.),put(crt,z2.),put
(id,z5.));
 
output;
 
end;
 
end;
 
end;
 
run;
 data tstndx1(index=(pid/unique study stycrt=(study
crt)));
  do study=1 to
30;
     do crt=1 to
10;
          do id=1 to
10000;
              pid=cats(put(study,z2.),put(crt,z2.),put
(id,z5.));
 
output;
 
end;
 
end;
 
end;
 
run;

/* EG CODE */
/* THERE MAY BE WAYS TO PREVENT THIS - BUT THIS WHAT A NAIVE EG USER
GOT
*/
proc
sql;
  CREATE TABLE WORK.TMP_0003 AS SELECT * FROM
WORK.TSTNDX;
QUIT;

PROC
SQL;
 CREATE TABLE SASUSER.Query2_for_TSTNDX1 AS SELECT
TSTNDX1.pid,
       TSTNDX.pid AS
pid1
 FROM WORK.TSTNDX1 AS
TSTNDX1
        INNER JOIN WORK.TMP_0003 AS TSTNDX ON (TSTNDX1.pid =
TSTNDX.pid and TSTNDX1.crt = 1)
 WHERE TSTNDX1.study =
6 ;
QUIT;

NOTE: PROCEDURE SQL used (Total process time):
     real time           0:22.00
     cpu time            0:36.34


/* MY CODE */
/* SAS CONNECT HAND CODING */
proc sql;
  create
     table sascon as
  select
     l.pid
    ,r.pid as pid1
  from
     work.tstndx1 as l, work.tstndx as r
  where
    l.pid  = r.pid and
    r.crt  = 1     and
    l.study= 6
;quit;

NOTE: PROCEDURE SQL used (Total process time):
      real time           0:01.00
      cpu time            0:01.75

This following...

  1. Enterprise Guide generates better and more reliable code than
programmers


...only applies to certain people who represent "The Best In Management
Thinking" and are therefore by default "The Worst when it comes to
Actual Management".

Technicallly competent people know EG was designed for specifically
people who can recognize a computer from a distance, but only because
their kid is playing games on Facebook.com.

I think there has been an omission from the quote, which should have
said something like:

1. Enterprise Guide generates better and more reliable code than
programmers who don't use SQL

Hand coding SQL can produce code that is more efficient than EG, but
equally could be less efficient.  I'd like to think of myself as a
technically competent person, and I use EG every day, but I only use the
Query tool for quick data investigations when I can't be bothered to
write efficient code.  I use the Code Window the rest of the time to
write code in the same way non-EG coders do it.

Finally, this question is trying to get my attention, so I will give it
an airing here:
  How many critics of EG on SAS-L have actually used it for real work
for more than a few hours?  Viewing from afar can create myths, e.g. the
canals on Mars, the Moon is made of cheese, etc.

...........Phil Holland
(Author of "Saving Time and Money using SAS"
and "Power User's Guide to SAS Programming")

In message
<bb01cc45-529d-4811-bddd-3f319037e9b6@31g2000vbf.googlegroups.com>,
montura <monturainc@gmail.com> writes
>This following...
>
>  1. Enterprise Guide generates better and more reliable code than
>programmers
>
>
>..only applies to certain people who represent "The Best In Management
>Thinking" and are therefore by default "The Worst when it comes to
>Actual Management".
>
>Technicallly competent people know EG was designed for specifically
>people who can recognize a computer from a distance, but only because
>their kid is playing games on Facebook.com.

-- 
--------------------------------------------------------
Holland Numerics Ltd
        94 Green Drift, Royston, Herts SG8 5BT, UK
        mobile : +44-(0)7714-279085
        email  : <NEWS@hollandnumerics.com>
        URL    : http://www.hollandnumerics.com/
--------------------------------------------------------

On Dec 6, 8:56=A0am, Phil Holland <n...@hollandnumerics.com> wrote:
> I think there has been an omission from the quote, which should have
> said something like:
>
> 1. Enterprise Guide generates better and more reliable code than
> programmers who don't use SQL
>
> Hand coding SQL can produce code that is more efficient than EG, but
> equally could be less efficient. =A0I'd like to think of myself as a
> technically competent person, and I use EG every day, but I only use the
> Query tool for quick data investigations when I can't be bothered to
> write efficient code. =A0I use the Code Window the rest of the time to
> write code in the same way non-EG coders do it.
>
> Finally, this question is trying to get my attention, so I will give it
> an airing here:
> =A0 How many critics of EG on SAS-L have actually used it for real work
> for more than a few hours? =A0Viewing from afar can create myths, e.g. th=
e
> canals on Mars, the Moon is made of cheese, etc.
>
> ..........Phil Holland
> (Author of "Saving Time and Money using SAS"
> and "Power User's Guide to SAS Programming")
>
> In message
> <bb01cc45-529d-4811-bddd-3f319037e...@31g2000vbf.googlegroups.com>,
> montura <montura...@gmail.com> writes
>
> >This following...
>
> > =A01. Enterprise Guide generates better and more reliable code than
> >programmers
>
> >..only applies to certain people who represent "The Best In Management
> >Thinking" and are therefore by default "The Worst when it comes to
> >Actual Management".
>
> >Technicallly competent people know EG was designed for specifically
> >people who can recognize a computer from a distance, but only because
> >their kid is playing games on Facebook.com.
>
> --
> --------------------------------------------------------
> Holland Numerics Ltd
> =A0 =A0 =A0 =A0 94 Green Drift, Royston, Herts SG8 5BT, UK
> =A0 =A0 =A0 =A0 mobile : +44-(0)7714-279085
> =A0 =A0 =A0 =A0 email =A0: <N...@hollandnumerics.com>
> =A0 =A0 =A0 =A0 URL =A0 =A0:http://www.hollandnumerics.com/
> --------------------------------------------------------

Hi Phil,

Thanks for the response. We really need more of this kind of analysis
and I hope others will jump in to support of EG

>Finally, this question is trying to get my attention, so I will give it
>an airing here:
> How many critics of EG on SAS-L have actually used it for real work
>for more than a few hours?  Viewing from afar can create myths, e.g. the
>canals on Mars, the Moon is made of cheese, etc.

Phil, The link points you to Nth consultancy, which has experts in EG.
Yet careful reading of the publications raises many questions from
several SAS-L posters. We have heard from the experts at Nth.

For me your criticism above is absolutlely true, I have only about two
weeks use with some production code algorithms, what we need are
example SAS programs where EG outperforms SAS-Connect, has critical
added functionality and greatly improves productivity over SAS-Connect
for SAS programmers. I have made it clear in capital letters that I am
not an EG expert and my comparison may not be accurate. I will
continue to investigate EG. I need help, if anyone has publications,
EG experience beyond mine or is willing to update my findings please
step forward. I know there are strong proponents of EG because
companies are embracing this technology.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 1. Enterprise Guide generates better and more reliable code than
> programmers who don't use SQL

The exact line in the paper, unless there is something wrong with
acrobats is:

"Enterprise Guide generates better and more reliable code than
programmers produce manually"

I think you seem to believe in some cases EG produces better code than
non-EG SQL programmers. It has been theorectically proved that SQL is
a subset of a procedural language like the datastep. I can't find the
reference right now. The datastep can handle all the problems that SQL
can handle and many more. I think Codd recognized this.

> Hand coding SQL can produce code that is more efficient than EG, but
> equally could be less efficient

I think this is incorrect. I do believe a very skilled  non-EG SQL
programmer with the following non-sql constructs 'DOW loop/by x
notsorted/by patient/first dot/last dot/append /point=3D/merge/hash/
update/key=3D/modify/_IORC_=3Dupdate-delete-insert/VSAM/ISAM/
QSAM/'PASSTHRU to teradata/oracle/sql SQL server/mysql/IML  programmer
can produce code as efficient as SQL and deal with a much wider class
of problems. I don't think EG has any knowledge of SQL constructs in
other databases languages? I will test to see how the EG query handles
passthru to Oracle. I do believe the catesian join and join on
condition in SQL are powerful constructs which map to more complex
datastep programs. I know EG has no knowlwdge of EXCEL/ACCESS SQL
since you cannot set up a passthru query to EXCEL from EG, but you can
in a SAS connect environment.

From what I have seen a SKILLED non-EG SQL programmer will  always
(99%of the time) create more efficient code than EG/SQL or handcoded
SQL?, albeit the code may be more complex. A handcoded hash should
outperform a sqlhash? I think it has to do with theorectical
limitations of SQL. I don't think remerging is as efficient as
constructs like the DOW/et all. I may need others to agree or
disagree..

 From what I have seem, programmers learning SQL via the query tool in
EG will lead to some very strange programs.

Could you provide a query generated by EG that is more efficient than
an expert non-EG SQL programmer coud hand code?
Perhaps a catesian join on condition. Where old.date is between
new.orderdate and new.recievedate. I will look into this.
I have a simple hash solution for this. I have sql code to get the
median. I will compare running that SQL program in EG against non-EG
sql solutions available outside of EG-SQL. I can't imaging a need for
EG when the server is Windows Server. Terminal Server or Citrix makes
your desktop function like desktop windows SAS.

I can find no valuable functiionality in EG, except egp projects,
tasks and process flow that are not available in SAS-Connect
environment. I am trying to post similar tools on my site.  If you
read the Nth publications it appears that SAS does not provide
complete migration tools for projects and process flow. Also there are
validation concerns.I leave the issue of storing key meta data in
project files to the reader.

At this time I think users might be better of with UltaEdit/EMACS then
EG for communicating with the server. If I lose SAS-Connect but am
able to keep windows base SAS,  I will investigate sFTP over a
persistent SSH tunnel to submit code to the server. I think I can
overcome the password issue. I really want to be able to submit code
snippets and access unix work directories from windows.

I have only used EG for two weeks, so I know my comparisons may not be
accurate and I state that in capitals in my comparison. I would love
it if some EG expert would edit my findings, but the EG expert would
have to live with my assumptions of comparing EG to SAS-Connect. I
think this is onlly technical(not $) valid comparison for replacing
desktop windows SAS-Connect with EG. I know of at least two comapanies
that have entertained or made the decision to switch to EG.

SUPPORT FOR EG

1.  I support EG for non-progammers.

2.  EG allows NON SAS applications to access a SAS IOM server. The API
is published by SAS.

3. EG does have some interesting IT support functions for gathering
meta data from SAS objects. I am trying to post base SAS tools that
you can use to do many of the SAME functions on my site. This is
complex programming.

4. EG provides a 'psuedo' interactive interface to server SAS. I
believe SAS-Connect is better. You can highlight and submit code forn
EG to the server. However the code appears to be wrapped in the
undocumented? IOM COM environment and may not be executable outside EG
Also there are at least a couple of dozen base SAS language functions
that will not run using 'RUN SELECTION'. or UNIX batch. Some would not
run in UNIX batch through SAS-Connect, but SAS-Connect means you have
at least desktop WIndows avaialble to run those functions. I don't see
why EG running on the desktop cannot support these functions.

5. EG provides more menus for running SAS procedures. I feel a SAS
programmer would be better off using my syntax insert function in base
sas. I have the syntax for 63 procedures on my site.  Menus are ok for
non SAS proogrammers.


Regards

On Dec 6, 5:48=A0pm, xlr82sas <xlr82...@aol.com> wrote:
> On Dec 6, 8:56=A0am, Phil Holland <n...@hollandnumerics.com> wrote:
>
>
>
>
>
> > I think there has been an omission from the quote, which should have
> > said something like:
>
> > 1. Enterprise Guide generates better and more reliable code than
> > programmers who don't use SQL
>
> > Hand coding SQL can produce code that is more efficient than EG, but
> > equally could be less efficient. =A0I'd like to think of myself as a
> > technically competent person, and I use EG every day, but I only use th=
e
> > Query tool for quick data investigations when I can't be bothered to
> > write efficient code. =A0I use the Code Window the rest of the time to
> > write code in the same way non-EG coders do it.
>
> > Finally, this question is trying to get my attention, so I will give it
> > an airing here:
> > =A0 How many critics of EG on SAS-L have actually used it for real work
> > for more than a few hours? =A0Viewing from afar can create myths, e.g. =
the
> > canals on Mars, the Moon is made of cheese, etc.
>
> > ..........Phil Holland
> > (Author of "Saving Time and Money using SAS"
> > and "Power User's Guide to SAS Programming")
>
> > In message
> > <bb01cc45-529d-4811-bddd-3f319037e...@31g2000vbf.googlegroups.com>,
> > montura <montura...@gmail.com> writes
>
> > >This following...
>
> > > =A01. Enterprise Guide generates better and more reliable code than
> > >programmers
>
> > >..only applies to certain people who represent "The Best In Management
> > >Thinking" and are therefore by default "The Worst when it comes to
> > >Actual Management".
>
> > >Technicallly competent people know EG was designed for specifically
> > >people who can recognize a computer from a distance, but only because
> > >their kid is playing games on Facebook.com.
>
> > --
> > --------------------------------------------------------
> > Holland Numerics Ltd
> > =A0 =A0 =A0 =A0 94 Green Drift, Royston, Herts SG8 5BT, UK
> > =A0 =A0 =A0 =A0 mobile : +44-(0)7714-279085
> > =A0 =A0 =A0 =A0 email =A0: <N...@hollandnumerics.com>
> > =A0 =A0 =A0 =A0 URL =A0 =A0:http://www.hollandnumerics.com/
> > --------------------------------------------------------
>
> Hi Phil,
>
> Thanks for the response. We really need more of this kind of analysis
> and I hope others will jump in to support of EG
>
> >Finally, this question is trying to get my attention, so I will give it
> >an airing here:
> > How many critics of EG on SAS-L have actually used it for real work
> >for more than a few hours? =A0Viewing from afar can create myths, e.g. t=
he
> >canals on Mars, the Moon is made of cheese, etc.
>
> Phil, The link points you to Nth consultancy, which has experts in EG.
> Yet careful reading of the publications raises many questions from
> several SAS-L posters. We have heard from the experts at Nth.
>
> For me your criticism above is absolutlely true, I have only about two
> weeks use with some production code algorithms, what we need are
> example SAS programs where EG outperforms SAS-Connect, has critical
> added functionality and greatly improves productivity over SAS-Connect
> for SAS programmers. I have made it clear in capital letters that I am
> not an EG expert and my comparison may not be accurate. I will
> continue to investigate EG. I need help, if anyone has publications,
> EG experience beyond mine or is willing to update my findings please
> step forward. I know there are strong proponents of EG because
> companies are embracing this technology.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > 1. Enterprise Guide generates better and more reliable code than
> > programmers who don't use SQL
>
> The exact line in the paper, unless there is something wrong with
> acrobats is:
>
> "Enterprise Guide generates better and more reliable code than
> programmers produce manually"
>
> I think you seem to believe in some cases EG produces better code than
> non-EG SQL programmers. It has been theorectically proved that SQL is
> a subset of a procedural language like the datastep. I can't find the
> reference right now. The datastep can handle all the problems that SQL
> can handle and many more. I think Codd recognized this.
>
> > Hand coding SQL can produce code that is more efficient than EG, but
> > equally could be less efficient
>
> I think this is incorrect. I do believe a very skilled =A0non-EG SQL
> programmer with the following non-sql constructs 'DOW loop/by x
> notsorted/by patient/first dot/last dot/append /point=3D/merge/hash/
> update/key=3D/modify/_IORC_=3Dupdate-delete-insert/VSAM/ISAM/
> QSAM/'PASSTHRU to teradata/oracle/sql SQL server/mysql/IML =A0programmer
> can produce code as efficient as SQL and deal with a much wider class
> of problems. I don't think EG has any knowledge of SQL constructs in
> other databases languages? I will test to see how the EG query handles
> passthru to Oracle. I do believe the catesian join and join on
> condition in SQL are powerful constructs which map to more complex
> datastep programs. I know EG has no knowlwdge of EXCEL/ACCESS SQL
> since you cannot set up a passthru query to EXCEL from EG, but you can
> in a SAS connect environment.
>
> From what I have seen a SKILLED non-EG SQL programmer will =A0always
> (99%of the time) create more efficient code than EG/SQL or handcoded
> SQL?, albeit the code may be more complex. A handcoded hash should
> outperform a sqlhash? I think it has to do with theorectical
> limitations of SQL. I don't think remerging is as efficient as
> constructs like the DOW/et all. I may need others to agree or
> disagree..
>
> =A0From what I have seem, programmers learning SQL via the query tool in
> EG will lead to some very strange programs.
>
> Could you provide a query generated by EG that is more efficient than
> an expert non-EG SQL programmer coud hand code?
> Perhaps a catesian join on condition. Where old.date is between
> new.orderdate and new.recievedate. I will look into this.
> I have a simple hash solution for this. I have sql code to get the
> median. I will compare running that SQL program in EG against non-EG
> sql solutions available outside of EG-SQL. I can't imaging a need for
> EG when the server is Windows Server. Terminal Server or Citrix makes
> your desktop function like desktop windows SAS.
>
> I can find no valuable functiionality in EG, except egp projects,
> tasks and process flow that are not available in SAS-Connect
> environment. I am trying to post similar tools on my site. =A0If you
> read the Nth publications it appears that SAS does not provide
> complete migration tools for projects and process flow. Also there are
> validation concerns.I leave the issue of storing key meta data in
> project files to the reader.
>
> At this time I think users might be better of with UltaEdit/EMACS then
> EG for communicating with the server. If I lose SAS-Connect but am
> able to keep windows base SAS, =A0I will investigate sFTP over a
> persistent SSH tunnel to submit code to the server. I think I can
> overcome the password issue. I really want to be able to submit code
> snippets and access unix work directories from windows.
>
> I have only used EG for two weeks, so I know my comparisons may not be
> accurate and I state that in capitals in my comparison. I would love
> it if some EG expert would edit my findings, but the EG expert would
> have to live with my assumptions of comparing EG to SAS-Connect. I
> think this is onlly technical(not $) valid comparison for replacing
> desktop windows SAS-Connect with EG. I know of at least two comapanies
> that have entertained or made the decision to switch to EG.
>
> SUPPORT FOR EG
>
> 1. =A0I support EG for non-progammers.
>
> 2. =A0EG allows NON SAS applications to access a SAS IOM server. The API
> is published by SAS.
>
> 3. EG does have some interesting IT support functions for gathering
> meta data from SAS objects. I am trying to post base SAS tools that
> you can use to do many of the SAME functions on my site. This is
> complex programming.
>
> 4. EG provides a 'psuedo' interactive interface to server SAS. I
> believe SAS-Connect is better. You can highlight and submit code forn
> EG to the server. However the code appears to be wrapped in the
> undocumented? IOM COM environment and may not be executable outside EG
> Also there are at least a couple of dozen base SAS language functions
> that will not run using 'RUN SELECTION'. or UNIX batch. Some would not
> run in UNIX batch through SAS-Connect, but SAS-Connect means you have
> at least desktop WIndows avaialble to run those functions. I don't see
> why EG running on the desktop cannot support these functions.
>
> 5. EG provides more menus for running SAS procedures. I feel a SAS
> programmer would be better off using my syntax insert function in base
> sas. I have the syntax for 63 procedures on my site. =A0Menus are ok for
> non SAS proogrammers.
>
> Regards- Hide quoted text -
>
> - Show quoted text -

Hi SAS-Lers,

I just read about three dozen SAS Enterprise Guide papers on Lex
Jansen's site.

I really think we need to think about the other side of the story.
You won't find any of this in the 100+ papers that extol EG.

This following paper seemed to have the most meat.

http://www2.sas.com/proceedings/forum2007/218-2007.pdf

But it bothers me.

The modern versus old technology argument is constantly made.

"For this paper, it is assumed that you have access to a central IOM
server, and Enterprise Guide 4.1 installed on your
local client system. Note that the old SAS Display Manager does not
support these new technologies, and should not
be considered as a viable alternative to Enterprise Guide."

You can continue to use the old architecture but you are giving up the
substantial
advantages of this new approach to data management and analysis.

Stored processes appear to be the golden egg of EG.

But I have some concerns.

These following arguments may be wrong, but I think they are valid
questions. I hope an EG expert can prove me wrong.

       In the paper 13 of the 17 pages were somewhat complex screen
shots. I don't have problems with point and click and screen shots but
a scripting language that can be executed from the command line can
really boost productivity.
For instance I think I could eliminate the 'region' screen function by
creating a command macro "egstr region". Note I can easily add
arguments, for instance if  I want a default value "egstr region
canada", where canada is the default. EG does not have a command line
but windows SAS-Connect does.

         It seems many screens are needed to create a simple stored
process. Much is made of  the fact that all clients can execute stored
processes even without SAS on the desktop and stored processes are
easly web enabled. Can't users already exceute web enabled server SAS
programs? Unfortunately programmers cannot easily develop and test
simple macros without a doing all the meta data stuff? This seems
counter productive for most of my analyses.

         It seems to me that stored processes do not support macro
arguments from configuation text files and batch submission tools like
UNIX DEVEL or any of my batch scripting(PERL, ksh and wsh)  tools that
depend on text files for macro variables. I don't believe UNIX
makefile can be used with stored processes either?  I can easily pass
macro arguments to batch jobs using configuation files and PERL.

          The prefered method seems to get macro arguments from the
SAS meta data server. Key meta data should not exist in two or more
locations. It seems to me that the meta data should be stored in SAS
specialized catalogs? I may be wrong but I have worked for companies
that store critical meta data in Oracle, MS-Access, Sybase and even
EXCEL. I think there may be  performance issues if every macro has to
get all of its arguments from SAS meta data server or MS-Access, every
time the macro is called?. Is the meta data in specialized SAS
catalogs? Can these catalogs become corrupted?

         To pass argument values from the meta data to stored
processes do you have to use global macro variables?

=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The author stated that thie code below could not be run under display
manager. I just ran it from display manager without any error. The
point was that only EG could run this code?

Statement in paper.

Note that this program does not work in the SAS Display Manager, which
will abend with the message that you
cannot use a by statement in Windows mode. (It does work in batch mode
when run from the command line.)

I really do not like that global statement. I think it is required
when you prompt the user? I hope I am wrong.

%* Sales report Example - Display Product by Region;
%macro salesrpt;
    %global region;
    proc report data=3Dsashelp.shoes;
    by region;
    %if (&region ne ) %then %do;
    where region=3D"&region";
    %end;
    title "Sales by Product";
    footnote "Data are current as of &systime &sysdate9";
    column product sales;
    define product / group;
    define sales / analysis sum;
    quit;
%mend salesrpt;
%salesrpt;

Ran ok using interative SAS-Connect

NOTE: Remote submit to SERVER commencing.
MPRINT(SALESRPT):   proc report data=3Dsashelp.shoes;
MPRINT(SALESRPT):   by region;
MPRINT(SALESRPT):   title "Sales by Product";
MPRINT(SALESRPT):   footnote "Data are current as of 18:17 05DEC2009";
MPRINT(SALESRPT):   column product sales;
MPRINT(SALESRPT):   define product / group;
MPRINT(SALESRPT):   define sales / analysis sum;
MPRINT(SALESRPT):   quit;
NOTE: Remote submit to SERVER complete.

NOTE: There were 395 observations read from the data set
SASHELP.SHOES.
NOTE: The PROCEDURE REPORT printed pages 24-33.
NOTE: PROCEDURE REPORT used (Total process time):
      real time           0.00 seconds
      cpu time            0.02 seconds

From the paper:

One point that has been ignored up until now is that you cannot just
specify any old SAS program as a stored
process. The following example shows the required changes to the shoe
sales report (listed above as Example 1) to
get it to run as a Stored Process:   I think you need that global
macro variable for a prompted
variable?

*ProcessBody;
%STPBEGIN;
    %* Sales report Example - Display Product by
Region;
    %macro
salesrpt;
    %global
region;
    proc report
data=3Dsashelp.shoes;
    by
region;
    %if (&region ne ) %then
%do;
    where
region=3D"&region";
=20
%end;
    title "Sales by
Product";
    footnote "Data are current as of &systime
&sysdate9";
    column product
sales;
    define product /
group;
    define sales / analysis
sum;
=20
quit;
%mend
salesrpt;
%salesrpt
%STPEND;

You need to add two lines at the top and one at the bottom. In order
to pass parameters to the process, the comment
*ProcessBody; must appear first. This line can be omitted if no
parameters are passed to the stored process;
see the discussion of run-time parameters following.

Note the  phrase 'significant initial investment to set up the meta
data server and configure the stored process server'

SAS Stored Processes provide a way to implement client/server
distributed applications in SAS. With Enterprise 4.1,
it is relatively straightforward to convert existing code to a Stored
Process, which should pay immediate benefits for
programs that are run repeatedly. Of course there is a significant
initial investment required to set up the metadata
correctly and to configure the Stored Process server, but once this
has been done=97and it only needs to happen
once=97end users can, given the proper authorization, create
applications which are reliable, useful, and truly cool.

The paper demostrates how to prompt the user for region. I think
getting the argument value from the meta data is much more complex?

The stored process does not run under display manager: However the
%STPBEGIN and %STPEND were found.

ERROR: No logical assign for filename _WEBOUT.

%STPBEGIN;
    %* Sales report Example - Display Product by Region;
    %macro salesrpt;
    %global region;
    proc report data=3Dsashelp.shoes;
    by region;
    %if (&region ne ) %then %do;
    where region=3D"&region";
    %end;
    title "Sales by Product";
    footnote "Data are current as of &systime &sysdate9";
    column product sales;
    define product / group;
    define sales / analysis sum;
    quit;
%mend salesrpt;
%salesrpt
%STPEND;