Seems like engine SASIOLA is missing from the libname ... View more

 Have you tried to enable logging ?   http://support.sas.com/kb/56/743.html   ... View more

@webbm, you're right. There are certain logs that are very easy to spot and maintain, and there other's where you have no clue, especially on the mid-tier side.   From personal experience, I found it's really a learning process that you have to go through. Will you get an inventory of ALL the logs on the system ? I don't believe so. But it's necessarily a problem....   Some considerations: 1.) Run some OS commands that will list files and directories that contain something like "*log*". Yes, it's a fuzzy match. 2.) Then go through all logs and locations and make an inventory. As you go through them, you'll start seeing patterns emerge. 3.) If you are not reasonably sure about something, then rather park it (for now). Some logs are overwritten and some are really so small, it doesn't even warrant housekeeping. 4.) Over time, as you learn more about the system, you can refine your 'log housekeeping inventory' 5.) Also consider that many components in SAS are actually third-party components e.g. gemfire, so you will have to cast you research wider that just the SAS software. 6.) The above will probably carry you 95% of the way, personally I wouldn't worry too much about the other 5% unless it becomes a problem, or if you are looking for work at 2am 🙂   Good luck !     ... View more

Fully agree with the points made earlier.   I would also like to tag on another consideration, that being 'What hotfixes to apply ?'   There is a school of thought that says ALL available hotfixes should be applied. Given the complexity of rollbacks (as detailed in this post) and the fact that some hotfixes actually introduce new errors, I'm personally not of this opinion. My take is, if you have a specific problem that is fixed with a specific hotfix, then ok, go for it and follow the recommendations in this post. If you don't need a hotfix, you don't need it.   Then, the big one. Given that maintenance packs are cumulative of hotfixes and also introduce new product functionality, I'm firm of the opinion that maintenance packs should always be applied when released.   So what it comes down to for me is frequency of change vs. positive impact. By following my approach I feel that the system will stay relative bug-free with a low frequency of change, so you only need to worry about the whole rollback issue, a few times a year, if that. Maintenance packs are released few and far between. With maintenance packs you will (hopefully) go through a proper process that includes FULL backups, intensive UAT testing and a COMPREHENSIVE backout plan.   My 2 cents..... ... View more

XCMD is a Base SAS thing, not a SASGSUB thing, so regardless of how you invoke SAS, if the SAS session is XCMD enabled, like you have verified, then you should be good.   Just humor me and put your OS command in quotes, like below:   x 'env | sort > /userhome-dir/test.lst'; Also, have you tried running this command on the UNIX command line with the same user that runs the SAS job ? ... View more

The datasrc=in your libname must match the name you used in odbc.ini In this case they are different:   LIBNAME: SQLAnywhere_Butterfly ODBC.INI: SQLAnywhere_Butterfly_ini   It doesn't really matter what you call them, but they must match. ... View more

@LinusH is correct, it doesn't really make sense.   For splitting up SAS code, there are really three main scenarios:   1.) You have x number of SAS jobs that you can run in parallel e.g. my_job_1.sas, my_job_2.sas, my_job_3.sas. For this example I suggested the SASGSUB command since you can submit the three jobs to the Grid to run independently. 2.) You have a single SAS job e.g. my_job_1.sas, but WITHIN the job there are pieces of the code that you can run in parallel. This probably speaks more to your last example. In this case you would invoke grdsrv_enable(_all_,resource=SASApp) macro that will allow the pieces of SAS cdoe to be submitted to the Grid using SAS/Connect (rsubmit). 3.) A combination of 1.) and 2.)   Bottom line is, you have many tools in the Grid toolbox, but it really comes down to the design of the code and what you trying to achieve in terms of parallel processing/load management. This is your logical design. Once you have this defined , then it's easy to see what Grid tool you need. So it's not about 'Do I use 1, 2, or 3 ?' It's about what you are trying to achieve.   Hope it helps.....   ... View more

Run the below in your batch job. This will tell you if X commands are enabled for that particular SAS session.   proc options option=xcmd; run; ... View more

Ok, I get you.   Forgetting about Base SAS, what settings in E Guide are you looking to have different between the projects ? ... View more

So just as a departure point. It's not EG so much that gets pointed to a particular sasv9.cfg, it's Base SAS (local) that would use that.   There are a couple of those in effect, so we would need some additional context. ... View more

Submit your batch jobs using the SASGSUB command. This will distribute your jobs across the Grid according the policies you've set up.   http://support.sas.com/documentation/cdl/en/gridref/67371/HTML/default/viewer.htm#p1vejjepgd6q6nn1mwritxqdui82.htm   ... View more