Date:         Wed, 9 Feb 2000 22:21:34 +0100
Reply-To:     peter.crawford@DB.COM
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Peter Crawford <peter.crawford@DB.COM>
Subject:      Re: SAS conversion: let's discuss GLOBAL SCL CHANGE
Comments: To: clmakinson@goodyear.com
Content-type: text/plain; charset=us-ascii

well, why not...
so here is something like the tool I had in mind
....below


Datum:         09.02.2000 19:44
An:            Peter Crawford/Zentrale/DeuBaExt



Betreff:       Re: SAS conversion: let's discuss GLOBAL SCL CHANGE
Nachrichtentext:




This is done all the time on the mainframe; particularly when global code
changes are necessary.  But there we have the tools.  Also this is a
no-brainer in such PC platforms like VB... a mass change to all the modules
is easy.   Why not provide the tool and let the developer take whatever
responsibility necessary?



>>>>>>>>>>>
I posted such a global scl change to the list some time ago
It was based on building a list of macro variables containing the entry names
and piping that through the command line in a loop along with the change
command. At that time I used proc catalog to build the entry list
>>> but it is much easier with the dictionary.catalogs table
The target on which my confidence is built did not need to be handling frames as
well as program entries, but that should be no more complex than a case clause
in the sql
For frame entries there is the additional complexity that there may be no scl to
update or it may be going by some other name. In that situation the whole thing
should be controlled under some strong scl.
Further care may need to be taken to ensure appropriate autocalled macro
libraries are available.
Here are my (tested) suggestions for updating only scl entry types
/* you have to ensure the libnames are prepared beforehand.
   Except sashelp, sasuser, and maps -
   all others are going to be searched for scl entries which will be updated */

/* need this gen macro for the macro GlobIt */
%macro gen(base,n);
 %local i;
 %do i= 1 %to &n;
    &base&i
 %end;
%mend  gen;

%macro globIt( from=xxxxxxxx, to=yyyyyyyy, msg="c:\msg.txt") /cmd stmt ;
/* warning :-- this macro Gsubmits a PROC sql */
     %local  i eN stuff stuf2  %gen(x,1000);
     %let stuff =%str(
proc sql noprint;
   select  compress(
libname || '.' ||
memname || '.' ||
objname || '.' ||
objtype ) into :e1 - :e10000 ); /* but it uses no more than it needs */
     %let stuf2 =%str(
from dictionary.catalogs
where libname not in( 'SASHELP', 'SASUSER', 'MAPS' )
   and objtype = 'SCL'  ;
quit;
); /* end of stuff definition */
gsubmit "&stuff" ; /*building scl entry list */
gsubmit "&stuf2" ; /*building scl entry list */
     %let eN = &sqlobs ;
gsubmit "%put  _user_ ; " ; /* documentation */
     %do i = 1 %to &eN;
bui  &&e&i  ;
change "&from" "&to" all  IC ;
compile      ;
msg ;
file  &msg  append ;
end;
end;
     %end;
gsubmit "%put changed &eN entries  from &from to &to ;" ;
%mend  globit;
 /* test that with command (on command line, command bar, function key or tool
button
    %globIT( from=INIT, to= init, msg="\msg.txt" )
>>>>>>>>><(and that has been tested ) ****************/

Interestingly, I needed two macro vars to hold the sql because of the size
limitations of the "command line"
If your where clause needs to account for more libname exclusions, the command
size may become important