07-08-2014 11:07 AM
These catalog files are used in the same way in Unix as in Windows, really no difference when you have them as native files.
The issue is getting them in a native format as CEDA the ease known with datafiles do not exist with catalogfiles.
- recreate the catalogs by running the SAS code. SAS formats are examples of catalog member types.
There are many more types being stored in catalogs (source logs output are one of the oldest types)
- use a SAS conversion tool.
+ Proc import/export can work when going to the same or higher version. But the encoding must be the same when going to another machine.
This limitation on encoding is a blocking issue to get data into the University Edition that one is running utf8 not the common latin1.
+ SAS/connect can upload/download easily catalogs. It has less limitation of versions and machines.
he same exception with utf8/latin1 is applicable
07-08-2014 11:41 AM
You did not mention anything of involved SAS releases, machine types and environmental limitations.
I mentioned the normal global approaches as they are valid (there ar no more ways).
Not really something to base a recommendation on with that little background.
07-08-2014 11:45 AM
I don't know the answers to any of those things. I run SAS on a big linux server. Fairly regularly, someone delivers data with a sas7bcat formats file. Linux SAS won't open it. I'm looking for a simple solution to using it. I can get onto a PC-SAS machine and convert it, but am hoping there is a trick to skip that step.
07-08-2014 11:47 AM
Or tell the folks sending the catalogs to include a CNTLOUT data set that you can then use as a CNTLIN to recreate the formats.
07-08-2014 11:48 AM
This applies to the last 2 responses--many of these are old or second hand data and there is no way to do that. I wish I could!
07-08-2014 11:48 AM
Tell the users to use PROC FORMAT to dump the format catalog they have created to a DATASET and send that along with the data. Then you can use it.
Say the user has created a folder to store their data and formats and is using the libref MYDATA to point to that folder. After they have created their formats (or as part of sending you the data) they can run this step to create the corresponding dataset for the format catalog.
proc format lib=mydata.formats cntlout=mydata.formats noprint; run;
Then when you receive the formats.sas7bdat file you can convert it into formats. If you are just working on their files for a little while then perhaps you just want to store the formats into your WORK library. Say you have placed their files in a directory on your unix machine and create a libref PCDATA that points to it.
proc format lib=WORK cntlin=PCDATA.formats noprint; run;
07-08-2014 12:44 PM
1/ As long the version on Unix is equal or newer as the Windows version....
Use: proc export upload the export file (transport file) import that one in Unix.
2/ As it it are formats. The format procedure can export all formats to a SAS datasets (CNTLOUT) in Windows
do a upload of the SAS dataset and Import the format (CNTLIN).
Should work for most older approaches. I am in doubt with 9.4 using MLF formats and FCMP in a format. That is rather new.
3/ Formats are created by SAS sources. Are they available let them hem have delivered and use those to create the format catalogs.
Preferable is 3/ than 1/ and as last 2/ At all occasions some of these approaches should work.
Why is 3/ preferable? Well my doubts on the newer functions and you should have the original code for binaries. Formats can be seen as as compiled versions of the SAS code.
07-08-2014 02:46 PM
I apologize, it appears I have not been clear.
These sas7bcat format files are delivered to me without code or other documentation. The original programmers are long gone, and there is no one with access to their work. The people delivering them know nothing about their creation and there is no one to contact to get more information. So, the alternatives that require doing something different in creation of the formats are simply not possible.
07-08-2014 03:24 PM
Well only /3 is based on code that is delivered for recent build code with the coder being accessible preferred.
The /1 is a conversion of the catalog not needing anything but limited by restrictions in sas versions
The /3 is based on a conversion of catalog members only of the format type. No original code of sas creating that is required as just a conversion of format catalog type.
Probably having restrictions by eg fcmp types. As that is very new functionality in those cases the developer should be known.
07-10-2014 04:51 AM
As Peter has mentioned, there are not many SAS file conversions that I can't cope with. See http://www.hollandnumerics.com for my contact details, if you are interested.
07-10-2014 10:18 AM
Thanks, but I can do it the way I have been, I was just hoping for a simpler solution. It seems odd to me that SAS cannot detect and handle these files automatically but that appears to be the case.
07-10-2014 10:34 AM
I suspect the main issue is that CATALOGS in general hold much more than just formats. Much of that content could very well be OS specific. So trying to translate PC stored compiled code, or image formats, keyboard assignments, menu lists and window/dialog boxes to be compliant with UNIX or ZOS or other OS that SAS supports would be awfully expensive.