{"id":1912,"date":"2012-01-05T03:28:36","date_gmt":"2012-01-05T08:28:36","guid":{"rendered":"http:\/\/www.thejuliagroup.com\/blog\/?p=1912"},"modified":"2012-01-05T12:16:27","modified_gmt":"2012-01-05T17:16:27","slug":"sas-on-demand-stuff-with-stc-files-i-tried-for-the-hell-of-it","status":"publish","type":"post","link":"https:\/\/www.thejuliagroup.com\/blog\/sas-on-demand-stuff-with-stc-files-i-tried-for-the-hell-of-it\/","title":{"rendered":"SAS On-Demand stuff with .stc files I tried for the hell of it"},"content":{"rendered":"

I’ve spent about 35 years messing around with computers based on the assumption that most discoveries are not preceded by “Eureka!” but rather,<\/p>\n

“What the hell! May as well try it.”<\/p><\/blockquote>\n

Having my new computer pretty much dissolve in smoke (less than a month after I bought it!), I decided to continue my analyses of the Kaiser-Permanente data using SAS on demand . I had downloaded this as\u00a0 a .stc file a while back, and used PROC CIMPORT to read it in, with all the formats, which I have mentioned before, is really, really easy to do<\/a>.<\/p>\n

I wondered what would happen if I uploaded the SAS dataset, you know, the .sas7bdat file\u00a0 and the FORMATS catalog to the SAS On-demand server. Would it work?<\/p>\n

Short answer – kind of.\u00a0 SAS On-Demand is very forgiving when it comes to format errors. It appears to have the NOFMTERR option turned on by default. I’d leave it alone.\u00a0 Look what happens when I do a simple table analysis. I get a table – sort of.<\/p>\n

This table doesn’t use the formats.\u00a0 No one reading it would know that 3 = “6+ drinks daily”. If it was just one format, I could use a PROC FORMAT and re-create it. No big deal.\u00a0 There are hundreds of variables and thousands of lines of format code I’d have to write. My first thought of<\/p>\n

“What the hell, I’ll just drag and drop the folder with the formats”<\/p><\/blockquote>\n

was a failure.In fact, despite the fact that Filezilla shows that my format folder was uploaded, it doesn’t actually show up in the SAS server at all.<\/p>\n

\"Table<\/a><\/p>\n

I suppose I could at this point go read some documentation or SAS user group papers – there is plenty out there –\u00a0 on moving catalogs between systems. Seriously, where is the fun in that?<\/p>\n

I still had the original .stc file lying around so I thought I would see if I could use PROC CIMPORT with SAS On demand.<\/p>\n

I had read-only access to the SAS server because that is what the students have, and I wanted to replicate what a student could or could not do.<\/p>\n

I uploaded the .stc file using Filezilla (nothing special about Filezilla, I just happen to like it<\/a>).<\/p>\n

When I looked in my the SAS library for my class, I did not see the file, even though all of the regular sas7bdat files showed up there, but I thought, what the hell, I’ll try the CIMPORT any way.<\/p>\n

Then, I ran this code:<\/p>\n

libname mydata \"\/courses\/univ.edu1\/i_432400\/a_2469\/saslib\" access=readonly;
\nFilename readit \"\/courses\/univ.edu1\/i_432400\/a_2469\/saslib\/04219-0001-data.stc\" ;
\nproc cimport infile = readit library = work\u00a0 ;<\/code><\/p>\n

 <\/p>\n

Where the part in the quotes in the LIBNAME statement is the library for my course on the SAS server.<\/p>\n

and I got this error message:<\/p>\n

ERROR: This transport file was created by an earlier release of SAS that did not record encoding.\u00a0 If and only if you know<\/strong><\/em> this\u00a0file was created from a SAS session running a UTF8 encoding, you may set the ISFILEUTF8 CIMPORT option to T (for TRUE) to\u00a0tell us to proceed to import this file.\u00a0 If it was not created by a UTF8 session, then you must import it in a session<\/span>
\n encoding that is compatible with the session encoding that produced that file.<\/span><\/p>\n

If and only if I know<\/strong> this file was created running a UTF8 encoding<\/em> ? Are you kidding me? Despite all the best warnings from my mother not to touch things if you don’t know where they’ve been, I downloaded this off the Internet! It could have originally been encoded in Korean for all I know (it wouldn’t be the first time).<\/p>\n

But then I said to myself,<\/p>\n

\"Julia<\/a>“Self, wait a minute here. If it is<\/strong><\/em> in fact UTF8 encoded and I say that is true, then it will work. And if it isn’t true, what’s the worst thing that could happen? A gnome with a candy-cane hat jumps out of my computer and slaps me? Not very damn likely.”<\/p><\/blockquote>\n

So, I added the option, ran the statement like this<\/p>\n

proc cimport infile = readit library = work ISFILEUTF8=TRUE ;<\/p>\n

My program ran, my \u00a0SAS log showed all the formats were output, when I ran analyses, my formats were there and used.<\/p>\n

All was right with the world.<\/p>\n

Just to make matters more complicated, let me throw in this \u00a0— if you had NOT made the library ACCESS = READONLY and tried to write to your class’s SAS library you would get a DIFFERENT error about the formats coming from a different system and it would not have worked.<\/p>\n

My guess, and it is just a random guess, is that maybe the class library had formats that were inconsistent with the older ones being uploaded so there was a conflict, while, since the work library is just held in working memory, there was nothing there to be inconsistent with. I could like it up or Google it or something. But I didn’t.<\/p>\n

Yes, it IS amazing that they give people with my level of maturity passwords to high performance computers. I find it hard to believe myself.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve spent about 35 years messing around with computers based on the assumption that most discoveries are not preceded by “Eureka!” but rather, “What the hell! May as well try it.” Having my new computer pretty much dissolve in smoke (less than a month after I bought it!), I decided to continue my analyses of…<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[15,9],"tags":[],"class_list":["post-1912","post","type-post","status-publish","format-standard","hentry","category-open-data","category-software"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/posts\/1912","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/comments?post=1912"}],"version-history":[{"count":8,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/posts\/1912\/revisions"}],"predecessor-version":[{"id":1926,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/posts\/1912\/revisions\/1926"}],"wp:attachment":[{"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/media?parent=1912"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/categories?post=1912"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thejuliagroup.com\/blog\/wp-json\/wp\/v2\/tags?post=1912"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}