SAS On-Demand stuff with .stc files I tried for the hell of it
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 the Kaiser-Permanente data using SAS on demand . I had downloaded this as 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.
I wondered what would happen if I uploaded the SAS dataset, you know, the .sas7bdat file and the FORMATS catalog to the SAS On-demand server. Would it work?
Short answer – kind of. 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. Look what happens when I do a simple table analysis. I get a table – sort of.
This table doesn’t use the formats. 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. There are hundreds of variables and thousands of lines of format code I’d have to write. My first thought of
“What the hell, I’ll just drag and drop the folder with the formats”
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.
I suppose I could at this point go read some documentation or SAS user group papers – there is plenty out there – on moving catalogs between systems. Seriously, where is the fun in that?
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.
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.
I uploaded the .stc file using Filezilla (nothing special about Filezilla, I just happen to like it).
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.
Then, I ran this code:
libname mydata "/courses/univ.edu1/i_432400/a_2469/saslib" access=readonly;
Filename readit "/courses/univ.edu1/i_432400/a_2469/saslib/04219-0001-data.stc" ;
proc cimport infile = readit library = work ;
Where the part in the quotes in the LIBNAME statement is the library for my course on the SAS server.
and I got this error message:
ERROR: This transport file was created by an earlier release of SAS that did not record encoding. If and only if you know this file was created from a SAS session running a UTF8 encoding, you may set the ISFILEUTF8 CIMPORT option to T (for TRUE) to tell us to proceed to import this file. If it was not created by a UTF8 session, then you must import it in a session
encoding that is compatible with the session encoding that produced that file.
If and only if I know this file was created running a UTF8 encoding ? 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).
But then I said to myself,
“Self, wait a minute here. If it is 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.”
So, I added the option, ran the statement like this
proc cimport infile = readit library = work ISFILEUTF8=TRUE ;
My program ran, my SAS log showed all the formats were output, when I ran analyses, my formats were there and used.
All was right with the world.
Just to make matters more complicated, let me throw in this — 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.
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.
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.
Glad you had success, and that the scary IF AND ONLY IF statement didn’t frighten you away from the attempt.
I can’t tell you the number of times I ask a student or a client whose program won’t run “Did you try X ?” and they say, “No, I was afraid to.”
I always wonder, “Afraid of what?” That the computer police will come to your house and arrest you? Of being frowned at by a council of elders?
Seriously , try it. What the hell, it might work.
I know this is keeping you up at night and you’ve added your reckless use of ISFILEUTF8 to your list of sins to recount in your next confession.
I checked with the development team (the folks who added that message), and they granted you this dispensation: “if the data contains only 7-bit ASCII characters – then using ISFILEUTF8 is also acceptable”.
Whew! I know that’s a load off of your mind.
Thank heavens! I am so relieved.