An Idea Exchange for SAS software and services

Comments
by Super User
on ‎08-27-2014 10:16 AM

Am in two minds about this.  It is a reference to a directory or group of directories so should be succient.  I can see something like:

libname my_location_for_temporary_data_storage "c:\temp";

being used for instance.

From my side an organization tree would be more usefull, e.g.:

libname prod.data "c:\production_data\data";

libname prod.adam "c:\production_data\adam";

libname prod.adam.define "c...";

by Super User
on ‎08-27-2014 10:24 AM

Agreed!

But many larger sites use Intelligence Platform nowdays in some way, and the metadata name for a libref could be up to 60 chars, which should be sufficient for most naming conventions.

by Contributor jmic_nyk
on ‎08-27-2014 10:37 AM

Having an eg Oracle schema named 'marketriskdata' and having a need to distinguish between production and test leaves you with 7 (seven!) chars for at libref in SAS DMS. And there's still a lot of users running SAS the traditional way. One solution could be the dot notation suggested by RW9. But honestly - I don't see an argument not to skip the limitation. At the BI platform it's handled by the metadata layer - and I guess that behind that, the 'real' libref still holds 8 chars. So it's a workaround.

by Trusted Advisor
on ‎08-27-2014 01:28 PM

The metadata approach is using his own looooooong names that can be translated to that 8 long name.

It is a little bit a translation like the not understandable technical ID-'s in the metadata.  

I would not advice a naming that is having some naming dependencies llike prod into some code.

The better one is removing all that kind of dependencies so you code is not physical bound to anything and is able to run on every environment unchanged. (release management).

You could use sas macro0-variable having a limit of 32bytes containing a more random identity-key as libname.

   

That 8 naming limit still exist in z/OS as being the DDNAME . Within Unix (linux) it is based on a integer see: C file input/output - Wikipedia, the free encyclopedia   - File descriptor - Wikipedia, the free encyclopedia  the numbers 0,1,2 are reserved ones (Should be known).  That 8 name of the original SAS is translated to an internal FD-number to make is transparant. 

With a translation logical name, real OS name for all OS systems the naming limit can be bypassed.

When this naming translation would be retrievable and being adjustable IT would be a great enhancement at the SAS Foundation level.
That option for an adjustable translation table is a similar enhancement as the logical ordering of variables. That order is also having a translation under the cover.   

by Contributor jmic_nyk
on ‎08-28-2014 02:21 AM

I still don't see why a eg 32char name should not be possible and I still think the 8 char limit is an anachronism from the old days. After all, no one will dictate you to use long librefs if the change is made.

The portability would be nice but there's already so many things that work different on Windows, z/OS and Unix - and allocation of data/databases is one of them. Actually I think it is something your systems programmer should do for you. It should - in the perfect world - not be at part of the process/program.

Systems limitations on the OS? I don't care. Fix it! Why should I be limited by what z/OS can handle when I'm working on a Windows Server? :smileyconfused::smileyshocked:

The Prod/Test discussion is basicly a "governance thing". I agree that you should not have these bindings, but in real world you have them anyway (and one extra char does not help much in my example Smiley Happy )

by Trusted Advisor
on ‎08-28-2014 02:52 AM

When you would have understand my comment.

1/ There is already a translation being done for Windows/Unix numbers to names. Extend that and you will your longer names.

    This is a strange one: It makes your OS limitations (Windows/Unix) already invisible. You don't care about those numbers. Be happy it is the only logical way to get it functional working.

2/ Prod/Test is a governance thing, agree. In real world you do not need those dependicies.

    It is just bad coding practices and not knowing the alternatives fulfilling it.

Are you saying because of lacking those you are not willing to do something about that governance?

There is always pressure to get work done by release management and versions tools even if they are applicable with SAS tools.

What is happening with the metadata-approach:

You should not be coding any libnames by yourself. You can ask one loooong name to be used to be setup by your sas-admin. He will solve that naming in some way. Your freedom in coding should be get limited.

By the way, this is not what my vision is. I see this being done by SAS as their direction and their promotions/efforts.

3/ You do not wan't to know anything of OS limitations?

There are always a lot of them.   With this attitude you are showing the misperception between what IT can deliver and what user expectations are. This is also the reason why people with this attitude are seen as jerks that should be limited and not granted access to some parts. If you would have followed me I give a lot of comment on those directions of locking out and limiting options. The prerequisite for that there is a well cooperation understanding and no intended abuse of facilities (eg performance overload).  

by Super User
on ‎08-28-2014 03:54 AM

Hi,

Not so much on topic as my 2p's worth.  You could of course just assign macro variables in autoexec.sas to libnames and call them what you want:

libname XYZ1234 "c:\temp";

libname XYZ1235 "c:\temp\prod" access=read;

...

%let Study_XYZ1234_Production_Area=XYZ1235;

...

Alternatively if there are many libraries, then utilize a lookup table.  I only note this as it is very rare in code that I will assign libnames, these are automatically assigned on a project level.

by Contributor jmic_nyk
on ‎10-09-2014 04:40 PM

All I have seen until now is workarounds - not a solution. I really don't see any reason why we as users should be limited by a 8 char restriction on the libname. Everything else has changed - it was great when we were able to use long variable-names.

Let's leave it here.

by Super User
on ‎10-09-2014 07:06 PM

With something like 2E12 possibilities with 8 character limitation I really hope that no one is running out of libname or filename possibilities.

I really have no interest to keep typing ThisRealLongLIbrayName.ThisEvenLongerAndPossiblyNexttoimpossibletospellright dataset name.

Idea Statuses
Top Liked Authors