Providing software solutions since 1976

• Log in
• Create profile
• Welcome
  [Log out]
• Edit profile

• Print  |
• Feedback  |
• Share

  • E-mail

  
  
  

  E-mail This Page

  Your Name:*
  Your E-mail:*
  Recipient E-mail:*
  Send a copy to me
  Personal Message:
  
  

  * indicates a required field

When a remote library is defined so that it references another remote
libref via the LIBNAME concatenation syntax, SAS VIEWs that are created
in the remote library might not be accessible from the client session.
And the following error message might appear:

   ERROR: File <library>.<filename>.DATA does not exist.

This is due to a problem with the underlying code that identifies the
proper entity to lock (and error messages to that effect will show up
in the SAS/SHARE server's log). The problem does not happen if the use
of concatenation is avoided.

An example of the problem can be shown as follows:

Server code:

   libname lib "C:\pathname";
   libname rlib (lib);
   data lib.vue / view=lib.vue;
      set sashelp.class(obs=3);
   run;
   proc server id=rmt authenticate=opt;
   run;

Client code:

   libname rlib server=rmt;
   data _null_;
      set rlib.vue;
      put _all_;
   run;

The above program fails when the RLIB.VUE view is referenced in the
DATA _NULL_ step, generating an error message:

   ERROR: File RLIB.VUE.DATA does not exist.

There are at least two ways to circumvent the problem, both of which
require the removal of library concatenation on the server. The first
uses the SLIBREF= option on the client LIBNAME statement to directly
refer to the library in which the view resides:

   libname rlib server=rmt slibref=lib;
   data _null_;
      set rlib.vue;
      put _all_;
   run;

The second method changes the way the server library is defined so
that it directly points to the physical location of the primary
library:

Server code:

   libname lib "C:\pathname";
   libname rlib "%sysfunc(pathname(lib,lib))";
   data lib.vue / view=lib.vue;
      set sashelp.class(obs=3);
   run;
   proc server ....

Either approach works, but the second allows the use of the RLIB
libref elsewhere in the server code if necessary. Either approach
can still use the underlying server libref.

NOTE: Neither of the above examples can use the remote server's WORK
libref in the place of the LIB libref, due to the inner partitioning
of the WORK library for the SAS/SHARE server's client subtasks. To
make use of the server's client WORK partition, you would have to
define the view from the remote side, and this only with compatible
architectures.  For example,

Client code:

   libname foo server=rmt slibref=work;
   data foo.vue / view=foo.vue;
      set sashelp.class(obs=3);
   run;
   data _null_;
      set foo.vue;
      put _all_;
   run;

A similar problem exists for remote views under SAS/CONNECT;
see SAS Note  #013931 .


A fix for SAS 9.1.3 (9.1 TS1M3) for this issue is available at:

http://www.sas.com/techsup/download/hotfix/e9_sbcs_prod_list.html#013932

Operating System and Release Information

A fix for SAS 9.1.3 (9.1 TS1M3) for this issue is available at: