Use the folder in an libname statement, then check sashelp.vmember.
[pre]libname check "path";
proc sql print;
select count(*) as CatalogCount
where libname = "CHECK" and memtype = "CATALOG";
select count(*) as DatasetCount
where libname = "CHECK" and memtype = "DATA";
That information is contained in either the Engine/Host output object from PROC CONTENTS, or in the DATAREPNAME variable from SASHELP.VTABLE or the DICTIONARY. equivalent of SASHELP.VTABLE. To create a SAS dataset from an ODS output object, use the ODS OUTPUT statement. To create a SAS dataset from a query against the SASHELP or DICTIONARY dataset, use SQL techniques, as shown previously.
User group papers that outline how to use SASHELP.VCOLUMNS or DICTIONARY.COLUMNS will probably also have information on these tables as well.
SASHELP.VCOLUMNS is a VIEW and as such is built when requested. Since it contains one row for every variable, in every table, in every library available to SAS, it can take awhile. PROC CONTENTS with an OUT= option for a specific libref is usually faster.
proc contents data=mylib._all_ out=cont;
See today's tip of the Day on sasCommunity.org.
seems a bit cheeky to add to an ArtC posting but feel it is worth offering PROC SQL.
An SQL where clause testing just LIBNAME will be very much faster than the equivalent data step.
In sql sashelp.vcolumn should provide information more quickly if the sql has a WHERE clause explicitly restricting the query to named libraries. If functions or expressions in the where clause can only be satisfied by reading table information (like nobs, last modified date or column format) then sql will be just as slow as the data step.
Good point Peter. In the DATA step the WHERE is applied after the view instructions have been executed (even a WHERE= on the SET statement), however in a SQL step, the WHERE is applied as the table is being built from the view. Thus using the view in a SQL step, with a WHERE, can result in huge savings.