Quentin , The arm logging see: https://en.wikipedia.org/wiki/Application_Response_Measurement is an open standard for the purpose you are describing. SAS is one of the few adapters of that. Why build something by your own when the movement is that other direction, ... View more

In your situation sas DI jobs on Unix SAS is installed on Unix not Windows.   The fist thing for working SAS on Unix is understanding Unix than getting access to by SSH on the same machine so you can see your processes running (ps). As you need SSH the NOXCMD setting from SAS to Unix is humbug. It is a signal there is no alignment with your IT department. Start there...  ... View more

I would try to forget to focus on traditional very ancient logging features. Sometimes they still are working sometimes you are hurting yourself. The new logging feautures are build around: - http://support.sas.com/documentation/cdl/en/armref/64756/HTML/default/viewer.htm#p1ok36twyl2u3qn1aj14dpjjcvdo.htm   That is where the APM tool the eventmanager are build on. The configuration of this has options to set alternate logs having defined events even a complete copy of the usual log. - The ODS part delivering output is abandoning the old classic text single based file that is based on with "proc printto". That is something conflicting. As you are mentioning a Linux log. Look at the options for parallel processing. It is the next thing to think about organizing your own work in more independent smaller pieces. I know it is very difficult to change patterns of behavior.  ... View more

It is about understanding the hardware and processes. You have tow of them. Getting Oracle to SAS en working in SAS datasets. All data is transferred in blocks with sizes of 512 byte 4K 64K and more. The less conversion is needed the better the performance will be. The more data you can keep in memory and minimize needed IO the better the performance will be. Oracle: There must be some transfersize. You can check these and optimize that one and having minimized locking and conversions. You are seeming not to have issues with this one. save the possible questions for later.       As it is a DBMS the data is stored in pages of some size. this tuning is DBA work. Funny the same pagesize approach is done with SAS.  SAS  - Setting the pagesize low (8K) is adding overhead you could use one of 64k SAS(R) 9.2 Language Reference: Dictionary, Fourth Edition   Theis setting will be the page size (proc contents) of new datasets. - The bufno options is often not used. you could set it at 8, 16 or higer. it is the caching of the data (datasets) done by SAS. Normally the OS is dong the caching efficient enough but with big datasets and little memory (16G and 20G datasets) you can spoil the caching of the OS that is becoming negative for the performance. There are notes on that with sgio parameter https://support.sas.com/resources/papers/IOthruSGIO.pdf - Compresion=binary is RDC SAS(R) 9.2 Language Reference: Dictionary, Fourth Edition. It a zip like approach on the record (not the file) It will work well with datasets with many variables (long physical record)    - A pitty you are not on 9.3 or up 46954 - SAS® system option settings for best performance in UNIX and Windows environments The Alignsasiofiles is effective for that alignment to the OS. minimizing at that interface the conversions. The Ibuf and ubufsize are new settings with 9.4  as those options getting effective for the other internal used data    - Them memsize is te setting for internal measure sas usage. Some statistical procedures will need more. You could optimize sort by using as much as possible (memsize 4G sortsize 3Gb) for that. ... View more

That error is because you are using an Unix server not Windows and the current directory is set wrong by SAS and your IT staff did not correct that. 50345 - Changing the current working directory for the SAS® Workspace Server You can still use the proc export creating an excel file on UNIX SAS/ACCESS(R) 9.4 Interface to PC Files: Reference, Third Edition The trick is using the XLSX option for the DBMS name. See the table what is working on Windows and what on Unix. The XLSX option for the libname is new for 9.4 the export/import already do have them with 9. The ods tagset can generate a xml-file that is what it does and Excel can read that. The compression of the data can be problematic (sizing network).  ... View more

Tom, The "mounting" of a Windows environment into a Unix environment is technical possible with something like Samba (or part of those). The impact on the security approach is however getting you into nasty troubles. The reason is that basic concepts like LDAP and AD with Unix access controls do not match. That is why those tools are commonly banned for more secured environments. Uploading files( binary) to Unix is rather easy and do not harm any of those environments. Wanting to having a more direct interfaces and having access pc/files on Unix licensed you are free to use a "pc files-server"  The IT guys that installed that all should be that business aware they have accepted that user request and did that installation. That is going along  those guys understand the OS levels of both sides and the business. As there is already a problem seen on the OS level (home dir WS not set 50345 - Changing the current working directory for the SAS® Workspace Server) I am doubting on that.      ... View more

1/ your server serveruser and password must be real valid values as of some Windows domain the pc-files server is running in.  This fake names will not work. Ask the guy that installed the pcfilesserver on a Windowsmachine. 2/ That machine must not be blocked by firewalls. That should have been verified by the person of the deployment. ... View more

1/ Your location for the csv should follow the Unix conventions where you have placed that file (drag drop for transfer windows to eguide files) 2/ your current dir is not your home dir. You will get a lot of errors on that. Either be secure in specifying always a full path or let that defult location be corrected to normal standards (not the SAS default). ... View more

DartibaliRodrigo You are connecting to a machine in USA for EGuide. That is not your desktop that is a different (virtual machine desktop). Do not expect your local desktop is the same one as that virtual one.   What you do on your desktop with ODBC is not available on any other including that remote one. Obviously you tried something on that remote remote desktop op and than run into that first cli error. You maybe have coded a libname statement and run that on the server Eguide is connecting to getting that CLI Unix error message. There is you third machine to be aware of. The sas processes run on that Unix server not on your desktop and not on the same machine where EGuide is sitting. As you are needing the ODBC connection in your libname (SQL server?) you could specify all  options for that sas process on that Unix server.  That construction is of isolated machines is most likely done for preventing actions like placing the data by users. In that case you have to ask why and who made up those limitations.    ... View more

I remember : https://communities.sas.com/message/205459 you can specify all in the connection string  (saskiwi) ... View more

Zachary,  Doing things correctly should be defined more clear as there are many different players with different interests in this game. There is: 1/ Your business goals with the internal business sponsor. This is the where the ROI/TCO must be done. The BIA Business Impact Analyses at this area will make the requirements for the Confidentiality Integrity Availability (CIA) classifications that will lead to the IT implementations and specifications of the SAS installation. This is the theoretical approach, you have started with an installation and now trying to correct what is done to now known specifications. 2/ There is some in house IT department that is delivering IT that as some service (desktops applications Windows servers AD etc).  These guys are important as when you are not aligned with them you will come into nasty troubles in the short or long term. The bad start is the were not involved from the beginning. The good is they have let you do al lot on you own and you someone talking their language.  The common misalignment between IT departments and business is these days temporary overruled by the devops strategy. I don not know what your position is in your organization just make your plan with that.  3/ External suppliers like SAS or a fulltime external admin. They are commonly not aligned with your business goals they have their own. Let me start with your Installation verification (renewal updates/fixes) and a DR machine.  There should be something noted about that in you contract with SAS when it is machine based. When it is user based that could be little bit different.  You will need 2 other machines from your internal IT department for that. The DR can be a cold standby, the Inst/verify machine  must be up and running continuously as long as you are working on that. According to European law http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN (article 6) there should be no need for additional costly sas licenses for those additional machines. You need to mention those to sas.  It can be sas is claiming following those laws is illegal and wanted to be paid for those. There is your fist challenge to get tackled. Having those additional machines you have to achieve: a/ operational machine -> DR -machine    (image to be copied) will that run in your business DR policies     Question:  what about the more easy backup/restore issues?    b/ installation/verification   -> operational machine  (image to be copied  fall-back scenario to be verified).         Question: would you think a redeploy of an image or a manually build new system by instructions (sdw) is the way to go?   The other is your performance and hardware design setup question. You have seen that SAS is very IO intensive. The best thing is to optimize that IO. That is using internal hardware like SSD's top be used for SASWORK and having all data local on that machine. As network connections are always much slower they should be avoided. The SAN's however have the advantage of good availability (backup restore). Check the papers on performance by M.Crevar like http://blogs.sas.com/content/sgf/2014/10/08/configuring-sas-what-to-know-before-you-install/ As you are Eminer I am little surprised by your focus on using SMC for libnames. Eminer does not benefit from that very well. The SMC is hiding the libname and possible other options on you system. Your time could be better invested on those parts of tuning your system and getting to know how to optimize resource usage and/or appropriate algorithmes. ... View more

Very nice document as a start David. Comments: - The focus is only on technical parts. The sas user support is completely missing. What I think of is:    + performance checks/validation    + functional usage needs expectations that are possibly having impact.    + the user application life cyclemanagment (DTAP) and the segregation of dataminers that work with production to develop and deploy models.        Sometimes the resulted reports/data must be validated before getting published (also an acceptance production life cycle)    + (what is more on that) - Backup restore has many type of requirements there is a DR (cold), system failure reset and one to roll-back human errors on a single artifact.   That last one will need you to think on not having that full automatic backup but thinking of selecting one artifact in eg metadata/content server to be brought back. - Accounts missing is that segration in normal and service (and others). For service accounts you really do not want to have passwords. There are many way to eliminate those. Sudo ant Unix (runas / surrogate) private/public keys with passwordless login.  That last one is possible used with VA with cgroups (docker). That passwordless login is also an advice with AWS usage. I would add: - Check the integrity of the total installation without trusting suppliers on their blue eyes.  Validate/check everything to business requirements.        ... View more

Your request doesn't make sense.  The sasuser is the personal home location used for some global settings. This storage location is normally closed within an EI SAS deployment, users cannot store data there. When using Eguide it is possible to store data in the user profile location (home). This location is normally on a desktop a roaming profile that is copied to a central storage location and back. The whole thing is the used space should be kept as small as possible. When not educate and guide the users to store data in a shared location (application or organization structured). As there is a strong dependency you should keep these on the same same machine as that run sas-processes. e Let us assume you meant to store userdata (application or organization structured) to be used on different servers in the same Windows domain. The you need a trust to an ohter server as this machine where the sas processes need resources on another. See: SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition. It is the spawners account that needs that setting. The by SAS documented approach is having the local system account getting those trusts. I expect that gets block by compliancy reasons and you will needing a dedicated account for that. The local system account is designed to be local not a domain user.  Doe me remember the local system account is rather restricted as you cannot get Windows admin rights (privilege escalation needed) with that. ... View more