Date:         Fri, 11 Feb 2005 23:30:24 -0500
Reply-To:     "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Subject:      Re: Proc options error handling

Duh, and Duh.

I had a feeling I was missing things. Thanks to Team Westat (Randy Herbison
and Mike Rhoads) for the pointers.

It turns out that the "table" metadata (as distinguished from the "member"
metadata) automatically filter out the invalid names. This precludes the
need for the validation function.

But here's a somewhat interesting variation on the task. Suppose that the
requirement is to report the number of observations for the validly named
tables, and also report on the existence of the invalidly named ones. You
need to combine table and member metadata, so a merge or join is in order.
For example:

   proc sql;
   select names.memname,
          nobs,
          nvalid(names.memname)
           as valid label='Valid Member Name?'
    from
     (select memname       from dictionary.members
      where libname='MYLIB') as names
     left join
     (select memname, nobs from dictionary.tables
      where libname='MYLIB') as nobs
     on names.memname=nobs.memname;
   ;

The result:

                                        Number of     Valid
                                         Physical    Member
   Member Name                       Observations     Name?

   DATASET-1                                    .         0
   DATASET_2                                    1         1

If the NVALID function is not available, the join results can be inspected
to populate the last column; replace

   nvalid(names.memname)

with

   case when nobs.memname is null then 0 else 1 end

On Thu, 10 Feb 2005 23:13:18 -0500, Howard Schreier <hs AT dc-sug DOT org>
<nospam@HOWLES.COM> wrote:

>SASHELP.VMEMBER and DICTIONARY.MEMBERS will pass the invalid names and will
>not raise the ERROR condition which PROC CONTENTS does. I think that's
>because only PROC CONTENTS actually opens the data sets. That's also why
>P.C. gives you the observation counts; the other metadata vehicles do not.
>
>You could retrieve all of the names, using SASHELP.VMEMBER or
>DICTIONARY.MEMBERS, then filter out the bad ones. I don't think there is a
>function which validates SAS names, but it should not be too hard using
>available functions or perhaps a regular expression.
>
>Then you would have to go back to PROC CONTENT for the obsevation counts.
>That would probably take a macro.
>
>Or maybe there is an easier way.
>
>On Thu, 10 Feb 2005 11:03:51 -0500, Martin O'Connell <moconnell@GEICO.COM>
>wrote:
>
>>Hi all,
>>
>>I need to get a listing of SAS files in a library and for each file I need
>>the number of obs in each.  This I do by:
>>
>>proc datasets memtype=data nolist;
>>   contents data=mylib._all_ out=mylibcontents (keep=memname nobs)
noprint;
>>quit;
>>
>>Normally this works fine.  But this morning another developer renamed a
>>member dataset_1 to dataset-1 which caused my code to fail.  He did this
>>outside of SAS (using OS commands).
>>
>>My question is this: Can I guard against this condition in the sense that
>>the offending dataset(s) will be skipped in the output?  I am only after
>>info on my files (this is a shared directory) which I know will be rightly
>>named.
>>
>>Thanks much for any help.
>>
>>Martin