Date: Wed, 16 Jan 2002 00:07:38 -0800
Reply-To: Stephan <skrause@DVD-SYSTEMPARTNER.DE>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Stephan <skrause@DVD-SYSTEMPARTNER.DE>
Organization: http://groups.google.com/
Subject: Re: Export SCL-Code to File in ASCII
Content-Type: text/plain; charset=ISO-8859-1
Hi,
thank you for your hints. They are as valueable as the last one you
gave me. I'll use a modified solution via popup-menu because the
second one is printing the code with informations like date and title
and so on.
Stephan
"Richard A. DeVenezia" <radevenz@ix.netcom.com> wrote in message news:<a1uurg$ihb$1@slb5.atl.mindspring.net>...
> "Stephan" <skrause@dvd-systempartner.de> wrote in message
> news:d447d7d1.0201132359.1e749948@posting.google.com...
> > Hi,
> >
> > for versioning my code I'd like to export my SCL-entries to my
> > filesystem for CVS. I need ascii for CVS comparing the versions
> > because binary files are compared only via date of change. And that's
> > an attribute SAS is changing almost everytime I look at an entry.
> >
> > What I've tried is to export data via cport. But this command creates
> > files in binary code not in ascii. With the file command I would have
> > to open the entry.
> > Is there any way to automatically open and close a window (for the
> > file command) or to export an entry in ascii?
> >
> > Regards
> >
> > Stephan
>
> I can understand your desire to maintain code in a CVS system. However,
> before you go through the trouble of working up some export/import
> management scheme, consider the looking at the Source Control Manager (SCM)
> utility provided with SAS/AF. Sure, you are locked into SAS's management
> tool and philosophies, but it may be sufficient for your needs.
>
> Type HELP SCM in the command window for more info.
>
> As for external CVS:
>
> export
> ------
> In the Explorer window, you can configure an action to save an SCL entry to
> an external operating system file.
> Tools/Options.../Explorer; Catalog Entries; SCL type; Edit
> Add
> Action: E&xport
> Command: BUILD %8b.%32b.%32b.%8b;FILE "c:\temp\scl\%8b\%32b\%32b.%8b"
> replace;CANCEL
>
> This action would require you having the folder c:\scl\<lib name>\<catalog
> name>\ pre-existing.
>
> import
> ------
> If the entry already exists, you can import from external file similarily.
> This action would have to be enhanced to handle cases where expected
> external file does not exist.
> Action: I&mport
> Command: BUILD %8b.%32b.%32b.%8b;CLEAR;INCLUDE
> "c:\temp\scl\%8b\%32b\%32b.%8b" replace;END
>
> For other explorer action possibilities see my page
> http://www.devenezia.com/downloads/sas/af/index.php, General Tips, SAS
> Explorer
>
>
> To export all SCL entries of a catalog you could try coding a macro to run
> something like
> PROC BUILD BATCH CAT=... ;
> PRINT SOURCE PRTFILE=... SELECT=(<entry name 1>.SCL);
> ...
> PRINT SOURCE PRTFILE=... SELECT=(<entry name N>.SCL);
> ;
>
> To import all files in an external folder, you could work up a macro to
> dynamically create or replace SCL entries (as shown in an earlier post
> regarding dynamic class SCL)
>
>
> What would be best for us developers, but probably won't happen, would be
> for SAS to implement two things.
> ###########
> 1. A transparent catalog merge with an external folder. All files with an
> SCL extension would appear in a libname.catname.
> This is already partially present in same-named catalogs in two different
> folders, where the two folders are in a concatenated libref. Every entry in
> each same-named catalog is available in the catalog when referenced through
> the concatenated library.
> This is powerful stuff.
> Why? You can test modified code simply by changing a libref to use a
> concatenated path where the path containing the updated code catalog comes
> earliest. To restore original codebase, remove test path from libref.
>
> options noxwait;
>
> x mkdir c:\tmp\a;
> x mkdir c:\tmp\b;
>
> libname a "c:\tmp\a";
> libname b "c:\tmp\b";
> libname ab ("c:\tmp\a" "c:\tmp\b");
>
> filename sa1 catalog "a.mycat.entry1.source";
> filename sa3 catalog "a.mycat.entry3.source";
> filename sb1 catalog "b.mycat.entry1.source";
> filename sb2 catalog "b.mycat.entry2.source";
>
> data _null_;
> file sa1; put "%sysfunc(pathname(sa1))";
> file sa3; put "%sysfunc(pathname(sa3))";
> file sb1; put "%sysfunc(pathname(sb1))";
> file sb2; put "%sysfunc(pathname(sb2))";
> stop;
> run;
>
> proc catalog cat=a.mycat; contents;
> Contents of Catalog A.MYCAT
> # Name Type ...
> 1 ENTRY1 SOURCE
> 2 ENTRY3 SOURCE
>
> proc catalog cat=b.mycat; contents;
> Contents of Catalog B.MYCAT
> # Name Type ...
> 1 ENTRY1 SOURCE
> 2 ENTRY2 SOURCE
>
> proc catalog cat=ab.mycat; contents;
> run;
> Contents of Catalog AB.MYCAT
> # Name Type Level ...
> 1 ENTRY1 SOURCE 1
> 2 ENTRY2 SOURCE 2
> 3 ENTRY3 SOURCE 1
>
> In the contents of ab.mycat you see an additional column, LEVEL, which
> indicates which folder of the concatenated list of folders is supplying the
> catalog entry.
>
>
> ###########
> 2. For windows users, provide a Windows Shell Namespace Extension to allow
> operating system level access to at least read SCL catalog entries. The
> best extension would also handle updating SCL entries of a catalog.
|