It depends whether you want to synchronise every user account or some of them only, in other words does the scope of your syncho process involves a restriction list ? The %MDUCMP user import macro can take into account such exceptions list. In order to run safely the synchronisation task based on "importpw.sas", you should then procede in 3 or 4 steps : 1. backup your metadata 2. define your exceptions list, if any. This might require updating the user account 'external identity' information with the SMC (General Tab) 3. purge every user account registered in metadata  - proc metadata, metadata data step or manually using SMC  - excepted the above mentioned exceptions in addition to the @saspw default technical accounts ! 4. run the syncho code once, then regularly. The initialisation step no.3 should prevent any conflict with existing accounts. Now, as regards the authentication process, take care to use one source directory and only one for your users account. Having two or more competing authentication domains for your user accounts is not recommended, ACFARRER above asks a good question : you might also strongly consider isolating service accounts with a specific Auth. Domain. Have a look at this clear-cut paper by Charyn Faenza, presented at the last Global Forum,even if it adresses Windows authentication issues, it could be helpful for Unix/Linux as well : 3479 - SAS® Metadata Security 101: A Primer for SAS Administrators and Users Not Familiar with SAS https://sasglobalforum.activeevents.com/2015/connect/fileDownload/session/9CF651E6B76F88D03DC9B600BBA81366/3479_Faenza-Paper%203479-2015_Faenza.pdf ... View more

Good point, Andrew. I interpreted - perhaps completely off the mark - the need in terms of usage statistics with complete coverage. Launching, on a regular basis , system commands on the filesystem storing SAS tables would give the information, of course, but only part of it : that kind of reports would display the size of permanent SAS tables; let's figure out a counter-example : if, between two audits (daily, weekly, monthly ?), the user removes or shrinks any SAS table permanently stored  then the corresponding information would be missing altogether. That's why it all depends on the admin's needs or expectations : the ARM API for instance, properly used, could provide extensive coverage of any SAS tables accessed , not only the SAS tables permanently stored but any version of it stored at any time and even the temporary tables used in SASWORK and deleted in the ensuing process. I know this distinction sounds a little bit like hair-splitting but, sometimes, admin experience SASWORK saturation caused by some reckless users who don't spare any space in their SAS EG session or even caused by concurrent SAS batch sessions consuming too much SASWORK put together. The complete coverage approach relates more to tracking & disk footprint measurement than simple auditing, sure. In that regard, being able to measure up the maximal footprint of a SAS session seems very useful for the admin though difficult to get. I know only of the ESM developed & sold by UK based Boemska company which gives this kind of (precious) details : https://boemskats.com/esm/ Good point also for reminding us about ALLOWXCMD. In the meanwhile, system commands can be replaced with SAS code for getting SAS tables sizes, even recursive research on large folder hierarchies : SAS Filesystem Toolbox - sasCommunity ... View more

Not easy to tell if you don't specify which product you are in charge of. There was a collection of reports called "SAS Audit and Performance and Measurement" to be implemented to your EBI installment ,now installed with the SAS Platform : SAS Audit, Performance and Measurement I am not sure this reporting tool included a metric about Dataset size (measured in Bytes and/or in Number of observations). Then there is the ARM logging API provided with SAS Foundation. Using this, you can enable your own logging but it requires some further coding & parameter changes : 35165 - Using restricted options to create dynamic Application Response Measurement (ARM) log files in UNIX environments https://support.sas.com/rnd/scalability/tools/arm/arm.html SAS® 9.4 Interface to Application Response Measurement (ARM) :: SAS(R) 9.4 Interface to Application Response Measurement (ARM): Reference I've become quite familiar with the ARM interface (on Windows, but this applies also broadly speaking to Unix/Linuw as well); A few guidelines : - be careful if you enable the whole set of ARM subsystems (eg ARM_ALL)  : your ARM log files shall grow very quickly in size; it's better to select the minimal subsystem which gives you the so-called 'metrics' (performances measures) you need & only thoses ones - with ARM_DSIO + ARM_PROC, you could trace the SAS table size in bytes (source table and target table) - the ARM refererence documentation (see above) itself does not cover everything; in particular, not only OLAP cube requests but SAS Data set size metrics are also recorded by ARM in addition to the volume of memory (RAM) used, for instance. I had to build my own technical doc in order to understand this Another possibility if you already have SAS batch sessions logs files at your disposal : enable FULLSTIMER option and parse the log files to store the relevant information. One last trick :you can request on-the-fly at any time the largest SAS table created in your session using the TABLES dictionary view proc sql; select max(filesize) as maxsize,libname,memname from dictionary.tables where not(libname in ('SASHELP','MAPS')) group by memname, libname order by maxsize descending ; quit; But, obviously, this is of a limited usage if you are looking for the largest SAS table created/accessed during every SAS session. ... View more

Yes, the system/security folder hierarchy has been available since 9.3 to include new objects like ACTs, Groups, User or Roles in the Package export/import process. http://bi-notes.com/2013/11/sas-administration-migration-users-groups-roles/ ... View more

Yes, I was curious to test quickly how the XML extraction process worked in order to use it in a batch step for updating the passwords. Then I discovered things were not so simple : SAS stored @saspw password in two components (1) Hash String / (2) Salt key.  Since I am not well versed in encryption/hacking wizardry, I can't tell how difficult this would be to reproduce the process. For me, at first sight this is not a piece of cake. Back to the original question, I suggest two possible workarounds : 1) change the user authentication directory : instead of internal (@saspw) authentication, use the company (Active Directory, LDAP etc.) exernal user database; this would take some time, but it is definitely safer and easier to maintain imho. It's not a recommended practice to create a separate user Directory, distinct from the default Directory because this opens a possibilly of hacking user's credentials and (unwisely) assigns to the SAS Admin the responsibility to prevent the security breach. Authentifying against the external Directory, like Active Directory can further improve both user's experience with SAS and password security if you implement Single Sign On (if available in your organisation) 2) Change the password updating process and transfer the task to the end user with  the Password Update Utility / Personal Login Manager (if still available in 9.4). ... View more

Sure, Kurt, but this would be a little bit like reverse-engineering at random : SAS might have re-used standard encryption techniques based on Unix (eg shadow), RSA etc. but it might have done otherwise, as well. :smileyconfused: If you have a copy of the technical specs, out of curiosity I'll be very interested  to have a look . I think this is typically grey area where no one outside the Dev team should have acces. ... View more

I am not quite sure if this is allowed or even technically feasible (outside SAS R&D powerful realm, that means). Try exporting your users using SAS Package (Folders tab / System / Security / Users). Then, open up the SPK archive and have a look at its content. The 'TransportMetadata.xml' file will show you the two attributes PasswordHash string and Salt key which store the internal password. Salted hashing make the encryption process very difficult to reproduce as far as I know. I guess SAS does not want to make public its encryption methods, which might be standard or not. I haven't looked at the OMI Java Doc about internal password update : I might be wrong, but I think the corresponding functions/methods are not provided for obvious reasons... There is the  SAS Deployment Manager  which can update some users internal login one by one, but not bulk load these kind of changes for thousands of accounts (as far as I know). There is also the 'SetPassword' utility, provided with SASPlatformObjectFramework set of tools. But then again, at least in 9.3, it can only update external passwords, not internal password @saspw. You can try also the Password Update Utility / Personal Login Manager (whatever it's called, if it still exists in 9.4), : 20961 - The Password Update utility is available to update login metadata on a per-user basis, it might be able to update a user's internal login password. Of course, you shall then deploy the tool on your users individual PC. Good Luck ! ... View more

Experts in their fields are all different, but they usually share this same motto : In the kingdom of the blind, the one-eyed man is king. (Proverb) How do Expert SAS professionals manage to remember and apply so many options/functions/concepts? 1. I would like to know how do you memorise and manage remember all of it? Legendary chess champion Capablanca or Alekhine (sources may vary) once replied to a reporter asking him How many moves ahead he was looking against his opponent, reportedly replied "I only looked ahead one move, but it was always the best move." Memory is unimportant. Memorisation is useless. Knowing by heart tens of thousand pages of SAS documentation won't serve you at all to become an expert. Sharpen your mind to answer with as much _relevance_ as possible. The personal decision rule you apply to select your choice does not depend of either how large is your memory, or how fast can you recall accurately some small piece of information. It depends upon how self-critical you are disposed to be regarding your own work .Self-criticism stands as a synonym for creativity. Dont'try to memorise, put at work your own way of doing things and test it mercilessly. To be more matter of fact, study both sample codes and the corresponding documentation, neither one of it independently. 2. Is there a knack you have developed to quickly  know where to look? No. Personally, as a junior developer, I was much inspired by a Senior SAS Coder who applied a subtle blend of innovative technics with proven ones , and based his technical choices also upon - sometimes unwritten - functional requirements. So I tried to start afresh each time and begin my journey by looking extensively for SAS code samples already available. Since Google has become our ubiquitous friend these last years, the only thing which can (could) save me time would be to learn how to type faster on my keyboard. Playing the piano can help (I suppose). 3. Even if you do, don;t you tend forget whatever you learned just like normal human beings do? I happen to know someone who possesses a fantastic memory, quite abnormal. He can remember almost instantly every line he as ever read, and he has read extensively from a very young age. Yet he's more often than not 'aloof' and absent-minded to the point of forgetting appointments all the time. Sometimes he doesn't even remind the name of the person he's talking to (funny to look at but embarrassing for the other person). Social forgetfullness can be quite an impairment sometimes; I don't envy the guy. "While differing widely in the various little bits we know, in our infinite ignorance we are all equal." (Karl Popper) 4. How long did it take for you to accomplish what you have so far?years/months? My accomplishments so far are too few to even mention. Time span doesn't count in my opinion. Some experts I know have developed amazingly in just a few years time. Other strive for many more years. I don't think their is common 'pace'. 5. If you achieved in a relatively short time, did you slog out reading voraciously for hours losing sleep? A few year's back, I remember standing up at night when my first daughter was born , reading the MIT Open Course Ware on-line materials (e g . Python introductory course). That kept me awake then when I needed to. However I cannot recall many things I read and now I would be unable to run the simplest code in Python, for instance. Sleep deprivation and training your skills are two different things, I guess. Please provide newbies some healthy and doable tips barring the 5th question, coz if that's the case I am afraid one would need to live a life after all. Make sense eh? Perfectly sense. Be what you are, expertise is just but a single word. Take your time to improve your own skills by observing how others have solved differently than you the same problem. Dig deeper into their solution. Other's ingenuity at work is always amazing. Some references to go further (Art Carpenter's SAS papers are my best source of inspiration) : http://www2.sas.com/proceedings/sugi23/Training/p275.pdf http://www.sascommunity.org/mwiki/images/c/ce/A_Walk_Thru_Time.pdf http://support.sas.com/resources/papers/proceedings13/029-2013.pdf ... View more

Some Excel functions are already implemented in SAS using FCMP custom functions : http://www.sascommunity.org/wiki/Excel_functions_in_SAS Complete doc for FCMP :  FCMP :: Base SAS(R) 9.4 Procedures Guide, Third Edition A nice presentation by SAS R&D : http://www.gasug.org/papers/ProcFCMP.pptx Here is, for instance, the Excel DATDIF function coded into SAS as a SAS function called DATDIF4_SLK : proc fcmp OUTLIB=SASHELP.SLKWXL.finance; function datdif4_slk(start, end)           label="European DATDIF";/*-----------------------------------------------------------------   * ENTRY:     datdif4_slk   *   * PURPOSE:   Returns the number of days between two dates using   *            the European '30/360' method of calculation.   *   * USAGE:     numdays = datdif4_slk( start, end );   *               start - the start date from which to calculate   *                       number of days, expressed as SAS date   *                       value, e.g., '15feb98'd.   *               end   - the end date from which to calculate   *                       number of days, expressed as SAS date   *                       value, e.g., '15mar98'd.   *   * NOTES:     If either start date or end date is on the 31st of   *            a month, then it is set equal to the 30th of the same   *            month. If the start date is on the last day of a   *            February, then the difference between 30 and the   *            length of the same year's February is added to the   *            usual U.S.(NASD) method of '30/360' day count basis.   *-----------------------------------------------------------------*/     startday = day(start);     startmon = month(start);     startyear = year(start);     endday = day(end);     endmon = month(end);     endyear = year(end);     if startday = 31 then                           startday = 30;     if endday = 31 then                         endday = 30;     restart = mdy(startmon,startday,startyear);     reend = mdy(endmon,endday,endyear);     datdif4 = datdif(restart,reend,'30/360');    /* adjust for february start and falls on the last day of february */     febstart = mdy(2,1,startyear);     marstart = mdy(3,1,startyear);     feblength = datdif(febstart,marstart,'act/act');     if feblength = 28 & startday = 28 then         datdif4 = datdif(start,end,'30/360') + 2;     if feblength = 29 & startday = 29 then         datdif4 = datdif(start,end,'30/360') + 1;     return(datdif4); endsub; run; quit; ... View more

I assume (wrongly ?) that the credentials (login,password) for your users are created and stored in some kind of external LDAP directory server (Microsoft Active Directory, SUN/ORACLE Directory Server, even Unix local passwd/shadow files). In this case, you don't create users with their credentials only inside the Metatada respository using internal logins (@saspw), which is generally  - and wisely - prohibited by security policies. So you need to synchronize your list of SAS users with all their attributes, their group in the first place, with the metadata repository. SAS provides such a set of tools called User Import Macros : User Import Macros :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide User Import Macros :: SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition The tool extracts user/group synchronized from both sources External LDAP (1) and SAS Metadata (2), then compares (1) with (2) and updates accordingly (based on your choice) the metadata appling the latest change coming from LDAP. There is also this note which provides a sample code easier to handle, excerpted from the User Import Macros : http://support.sas.com/kb/42/251.html ... View more

Yes, SAS provides Security Report Macros which should address your need : Security Report Macros :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide ... View more

Be careful, in order to natively process SAS tables encoded in UTF-8 (or UTF-16), you need to use another sas launcher, which means another SAS engine & another character functions (KSCAN , KSUBSTR etc.). http://support.sas.com/resources/papers/92unicodesrvr.pdf Unfortunately, SAS Foundation is installed in dual mode ISO (default) and UTF (called DBCS). Starting with DBCS has strong implications further. for instance, on Linux, the command line to lauch SAS DBCS with UTF-8 is the following : $SASROOT/SASFoundation/9.2/bin/sas_u8 -encoding utf-8 Back to your problem, using a Unicode SAS session might be unnecessary. You can try, in your default SAS (ISO) session assigning your Filename with the option ENCODING=utf8. SAS can transcode UTF to ISO (e g WLATIN1) at the import step and let you then code as usual. The target tables are then stored in ISO (WLATIN1), of course. FILENAME myfile 'my pathname' ENCODING=utf8; ... View more

Good advice. Thanks Paul. ... View more

Hi Paul, The so-called 'security model' is not affected by changing any attributes of the User. We all agree that it's preferable to keep a user name stable over time, especially since it often comes for the external directory (security requirement) and, as Andrew points out, is used as a primary key in the synchronization process (%MDU) between metadata and LDAP. The security model is like the fortress walls of defence, it doesn't go as far as the soldier's uniform (in my own personal view). It's not the same with the underlying Metadata Groups or Roles structure supporting the permissions : in this case, the distinction between Name and Display Name is pointless in my opinion ; as far as I know, there is only one default interface to display both and it's the SMC User Manager (+New Environment Manager). The Diagnostic Portlet of the SAS BI Portal is the only exception I can think of which also displays Groups and Roles (actual names). Besides at least wirh 9.2/9.3, the Display Name is not a required attribute for the Group or Role so that usually we simply omit to fill in the place with a value. Since the Group name might be used elsewhere as a security parameter : OLAP Dimension MDX condition, Information Map Group-based filter, we don't change it every week, of course : its naming must be stable over time. However, setting up a new model might involve many change of names and we speak of dozens of Groups / Roles on large multitenant platforms... The unability to change the names 'conveniently' using the User Manager implies tedious workarounds : 1. Systematically using the Display Name in addition to the Name : great, two values instead of one previously:smileyplain: 2. Purging/re-creating the Group / Role whenever we change our minds to rename it ... 3. Coding a new User Manager based on Metadata requests which adresses the need ... This new requirement might not be very cost-efficient in the long run. ... View more