You have to be clear about what you are doing, the first thing is, are you going: 1.1- to do an isolated department approach (not really strategic) 1.2- an enterprise approach with the expectation of a long term usage. In this case you will see two hierarchies, that are an: 1.2.a organizational one. This can be found in the bisecag as SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (organizational) and 1.2.b a work (project) related one SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition. claims to be having a functional approach but is showing divisions (organizational) Changing that word divisions into projects(or sas-applications) you are having a real functional approach. As the organizational structure is commonly very dynamic my vision is you need to do both of them. For projects you can follow a similar structure on the OS-level as in the SAS metadata level. There will be always data on the OS parts when going for advanced data processing. Having a RBAC (Role Base Access Control) proces in place with an IDM (Indentity Management) support you are getting aligned with those. I like the blogs of Gregory Nelson he is seeming to have the same kind of opinions as me. The admin role changed a lot. A day in the life of a SAS Administrator: Understanding the roles we play - SAS Users being more of advisory than a technical one. Having a grand design vision on how to manage projects (sas applications) you can go for more details. There are a lot of discussions at what place configurations should be made. The opinions are often based on a persons background. In a enterprise approach you are wanting a central managed (auditability traceability) one. You are getting into: 2.1 Some adhoc work is allowed it should by supported well as being the first visible for user-acceptance . Seeing the EGP (Eguide) methods on the desktop as the "solution" is not correct. Of course people grown as selfservice ones not cooperating with IT-staff will like the desktop only one. 2.2 Manage the configuration by doing some within the SAS-metadata administration. With a RDBMS DBA background this is often the only visible (removing redundancy as paradigm) way as similar to that RDBMS catalog. The world of a DBA is often limited not wanting to see OS files Bi Analtyics and all other topics outside his RDBMS reference world. For SAS macros formats (sas system options) and filenames are not managble from this point. There options for libnames 2.3 Manage the configuration by doing some at the OS-level administration and SAS configuration. There is a whole bunch of them see: SAS(R) 9.4 Intelligence Platform: System Administration Guide, Third Edition Nice is the post about the libname choices: Pre-assign SAS libraries? If so, which method? - SAS Users For a lot of usual used circumstances I believe you will good at the method of "pre assigned by external configuration". The reason is that it will give you more freedom to get compliant with release management and other processes. There are implementation errors by sas, they are described in some notes 38040 - Setting umask and ulimit values for SAS® sessions on UNIX and Linux there are some new options to set perms on a programmatic way in code. What is needed is a design concept for storing managing business project files. 50345 - Changing the current working directory for the SAS® Workspace Server . This is more a signal to some sas design mistake you should review. A design mistake by sas is the construct at the SASApp indicated as server-context in the admin-guide. Looking in those folders you will find directories that indicates sas is expecting the business project data/code to be placed in those subdirectories. It says every SASApp server-context has a 1-1 relationship with a project/business sas application, Needing more projects is needing more SASApp's. An enterprise will uses many projects. The problems: - code and data are different type of artifacts being managed different - code and data can have different technical ownerships. Anyway it is not SAS-institute owning (accountable) the customers business environment. - code and data can have different technical resource requirements. Anyway it is not very sensible to share those with the sas installation and sas configuration. For having a shared environment you could think of the default SASApp server-context serving that one and configure other server-contexts for each project / sas business application. Modifying config_usermods files accordingly will give a solution to your request. With well setup file systems and a structured way on your OS level you can solve the mentioned design issues by using soft-links (Unix) or the link command (Windows).
... View more
