At my presentation on using the DATA Step as a POP3 mail client somebody asked how to deal with attachments. For text-based attachments that is no problem. Binary files are more complicated. First you have to decode them (back from Base64 to binary) and then file them. Decoding is a piece of cake, but the filing part is giving me a headache. I could not open it.
Then I tried to read an Excel file (*.xls) and write it out again, just with INPUT; PUT _INFILE_; I could not open the copied file, although in the properties it looks identical (at least in byte count).
Next I did a comparison by reading the original file and the copy file and compare them byte by byte. No difference to see.
So I assume that there are certain hidden elements in those binary files that are not read or rewritten in this process.
Any suggestion what I might be missing and how to solve it?
I think the problem is that the filename statement does not handle the file attribute settings under windows and I don't see any options by which I could set them.
Although the contents of the files is identical, the properties windows are not. The original shows 3 tabs (General, Custom, Summary), the copy shows only one (General)
I have given up on finding out why the copying did not work, but I have been able to reach my original goal: converting a BASE64 encoded file into its original binary status.
If you want to do it in a DATA step, with FILE and PUT statements, the trick is that you have to write them as one continuous data stream. To do that you define a logical record length which is bigger than the biggest attachment you are handling. I tried LRECL of more than 1 MB and you use a trailing @ in the PUT statement.
The alternative is to use an external program like base64.exe and use a CALL SYSTEM to execute it.