4 ms·

I once worked on a piece of software communicating with a SAS instance (doing live decision management), but everything about it seemed sketchy. No one using it

I once worked on a piece of software communicating with a SAS instance (doing live decision management), but everything about it seemed sketchy. No one using it really liked it, and its internals always appeared like a blackbox to me. Also, either it is terribly engineered or the devs working with it were just bad - we wanted a JSON-based REST API, but they said that it's "not possible with SAS", so we fell back to badly organized HTTP calls with XML. Does anybody have some insights about internal quality and code "health" in SAS?

R_haterade 10y ago
Anecdotal, but our SAS decision support environment went down Friday. I can report back after the post-mortem if you like.
- blauditore 10y ago
  Yeah, would surely be interesting.
  - R_haterade 10y ago
    Nothing exciting to report. It was a resource-sizing problem and they didn't adequately separate prod and dev environments. Someone choked the dev and the prod went down with it.
    - blauditore 10y ago
      Thanks anyway for the insight!
bigger_cheese 10y ago
From experience I've found the "core" parts SAS Base, SAS GRAPH, OR, ETS etc are very stable. other parts we have had issues with in the past - Stored processes, LSF for scheduled jobs. SAS tech support have been pretty good though I believe my workplace pays a lot for the privilege of being able to contact them direct. One thing I have found is you can usually throw something together in a pretty "hackish" manner but typically there is a better and more optimal method of doing it which will be much more stable. Sometimes it doesn't hurt to ask tech support "What is the recommended method for doing..." Code which abuses the SAS macro language is especially notorious and a good candiate for asking this. A quick google tells me first class JSON support is pretty new (dec 2016). http://blogs.sas.com/content/sasdummy/2016/12/02/json-libname-engine-sas/ http://blogs.sas.com/content/sasdummy/2016/12/02/json-libnam... I don't know much about this all the A2A messaging is XML based in my org.

R_haterade 10y ago

Anecdotal, but our SAS decision support environment went down Friday. I can report back after the post-mortem if you like.

blauditore 10y ago
Yeah, would surely be interesting.
- R_haterade 10y ago
  Nothing exciting to report. It was a resource-sizing problem and they didn't adequately separate prod and dev environments. Someone choked the dev and the prod went down with it.
  - blauditore 10y ago
    Thanks anyway for the insight!

bigger_cheese 10y ago

From experience I've found the "core" parts SAS Base, SAS GRAPH, OR, ETS etc are very stable. other parts we have had issues with in the past - Stored processes, LSF for scheduled jobs. SAS tech support have been pretty good though I believe my workplace pays a lot for the privilege of being able to contact them direct. One thing I have found is you can usually throw something together in a pretty "hackish" manner but typically there is a better and more optimal method of doing it which will be much more stable. Sometimes it doesn't hurt to ask tech support "What is the recommended method for doing..." Code which abuses the SAS macro language is especially notorious and a good candiate for asking this. A quick google tells me first class JSON support is pretty new (dec 2016). http://blogs.sas.com/content/sasdummy/2016/12/02/json-libname-engine-sas/ http://blogs.sas.com/content/sasdummy/2016/12/02/json-libnam... I don't know much about this all the A2A messaging is XML based in my org.