$base64x80 function truncates encoded 454 length string to just 61 characters

[Jumboshrimps]

Tasked with parsing a 450+ encoded character string into SAS base64.
First was given the string, which I assigned to "lngstr" in a macro, then ran the string through "inputc(scan(lngstr,1)==,$base64x80);"                                                                                    
which works, (not really) as it only returns a partial result - no more than 61 characters.
Placing the same string in https://www.base64decode.org/ provides a completely different result, over 320 characters (I'm going with them as the correct answer).

Now I'm told these strings will be in a table from the client.                                                        
Making a test data set "Base64" with just one 454 length char string "lngstr" character variable, I'm having trouble using the $base64x80 function to generate any result at all. When I pasted the string into a variable in a macro and ran that variable through                        "inputc(scan(lngstr,1)==,$base64x80);" I got SOME result at least.       

data _null_;                                                                                                                                  
set Base64;
length session_id $1500;
session_id=inputc(scan(lngstr,1)==,$base64x80);
run;                                                                                                                                            

Log states:                                                                                                                               

121 data _null_;
122 set Base64;

123 length session_id $1500;
124 session_id=inputc(scan(lngstr,1)==,$base64x80);
-
390
200
76
ERROR 390-185: Expecting an relational or arithmetic operator.
ERROR 200-322: The symbol is not recognized and will be ignored.
ERROR 76-322: Syntax error, statement will be ignored.
125 run;                                                                                                                                        

My supervisor is saying maybe we should tell the client SAS can't do this as formated like this.
Is he right?
THANX.

[ballardw · Accepted solution]

Post the log in a text box opened on the forum using the </> icon to preserve formatting. The main message windows re-formats text so the diagnostic characters like the underscore in that error message no longer appears where it should. That location would be the place SAS first found something it could not process.

I'm going to guess it is under the equal sign where you use ==

Try

124 session_id=input(lngstr),$base64x80. ); 

Though I'm not sure how that works as you are not treating Lngstr as a macro variable as your description claims. Also you did not actually provide a Informat name which ends in . (period or dot) unless decimals are involved. InputC would accept an expression or variable that resolves to a valid Informat name but yours didn't. Plus I have no idea where that == comes from.

Modified from the online documentation of a test with this informat

data junk;
   x='d3d3Lm15ZG9tYWluLmNvbi9teWhpZGRlblVSTA==';
   val = input(x,$base64x80.);
   put val=;
run;

The 80 at the end of the informat basically says the result will be limited to 80 characters. So if you expect a longer value, say 1500 characters you should end the informat with 1500 not 80.

SCAN is going to return the characters up to the first of the following:

• If your computer uses ASCII characters, the default delimiters are as follows:

  blank ! $ % & ( ) * + , - . / ; < ^ |

  In ASCII environments that do not contain the ^ character, the SCAN function uses the ~ character instead.
• If your computer uses EBCDIC characters, then the default delimiters are as follows:

  blank ! $ % & ( ) * + , - . / ; < ¬ | ¢

So would could have truncated the input string as well.