About FriedEgg

FriedEgg · ‎06-08-2015

This is because the SAS session you started is most likely run with 'English' encoding and not 'Unicode.' So, while you are properly performing the encoding you are unable to store/view the unicode characters with the given session settings.

FriedEgg · ‎06-07-2015

You reasoning for using the CALL EXECUTE is to have you macro compile locally and transfer the generated SAS code/text to the remote server for execution. I understand why you feel this should be treated as a bug, but, I also feel that your approach is mostly what is flawed. As Linus said, the appropriate place to report bugs is with SAS Tech Support. In your specific example, rewriting the FOO macro to something like the following resolves all your issues: %macro foo; data _null_; foo = cat('x', repeat(' ', &k.), 'x'); len = length(foo); put len=; run; %mend; My recommendation would be to transfer the macro (even when compile in work on the client session) to the remote session and have it execute there. %let k=1000; %macro foo(session, k); data _null_; len = length("x%sysfunc(repeat(%bquote( ),&k.))x"); put ">>>&session. " len=; run; %mend; /* transfer macro FOO to remote, for non-shared file systems using PROC UPLOAD could be used instead of inheritlib option, this is example for MP-CONNECT style rsubmit */ options dlcreatedir; libname tmp "%sysfunc(pathname(work,l))/mstore"; proc catalog c=work.sasmacr et=macro; copy out=tmp.sasmacr; select foo; run; options noquotelenmax; %foo(local, &k.) signon t sascmd='!sascmd' inheritlib=(tmp); %syslput k=&k.; rsubmit t; options noquotelenmax; options mstored sasmstore=tmp; %foo(remote, &k.); endrsubmit; signoff t; data _null_; call execute('signon t sascmd="!sascmd" inheritlib=(tmp);'); call execute('%nrstr(%syslput k=&k.;)'); call execute('rsubmit t;'); call execute('options noquotelenmax;'); call execute('options mstored sasmstore=tmp;'); call execute('%nrstr(%foo(remote, &k.);)'); call execute('endrsubmit;'); call execute('signoff t;'); run;

FriedEgg · ‎06-05-2015

I am not certain what you mean by 'hangs' but I am going to assume you are referring to the effect of swait=yes (signonwait). This option will cause the client session to wait until the remote session has completed the sign on task and SAS is fully initialized before continuing to any following statements.

FriedEgg · ‎06-05-2015

This is not a bug, you have not programmed it correctly. Why are you even using the call execute's? That really only complicates things unnecessarily. Rather than walking through how to fix this example. If you care to share something closer to the situation you are actually dealing with (the SQL you mention...). It would be easier to help, I feel.

FriedEgg · ‎06-05-2015

data _null_; input foo $hex32.; bar=unicode(foo,'utf16b'); put bar; cards; 73B0572865B94FBF62537ED94F605417 ; run;

FriedEgg · ‎05-29-2015

, Nicely done. As usual.

FriedEgg · ‎05-29-2015

Kind of a misleading title on this... I was thinking the name suggests %TSLIT was developed for PROC TSSQL, it's also the procedure mentioned in the documentation internal to the macro itself. It's a useful little utility for surrounding a given string with properly single quotes, even when the input contains embedded full or partial quotes itself.

FriedEgg · ‎05-28-2015

One minor correction symget('sumlev') And yes, this will work and does not require the quoting or delimiting of the list and is viable with the example data (although may not be with your actual data, depending...)

FriedEgg · ‎05-27-2015

This is fine, once you have valid SQL, anyway. However, given your other post about adding the apostrophes, which used macro quoting, you need to %unquote() the macro variable for it to work correctly: %let a=%str(%'); %let sex=&a.M&a.,'F'; proc sql; select * from sashelp.class where sex in (%unquote(&sex.)); quit;

FriedEgg · ‎05-27-2015

%let apostrophe=%str(%'); *you should properly escape it; %let sumLevText = 1; *don't use "'s; %let sumLevText = &apostrophe.&sumLevText.&apostrophe.; %put >>>&sumLevText.;

FriedEgg · ‎05-21-2015

Using PROC GROOVY in SAS to Calculate Hash Digests

FriedEgg · ‎05-21-2015

@NG_Forest I updated the post to include a similar method using PROC GROOVY at the same link as above

FriedEgg · ‎05-21-2015

Here is an update to the above utilizing PROC GROOVY filename cp temp; proc groovy classpath=cp; submit parseonly; import java.security.MessageDigest; class Sha1 { public String encode(String message) { return new BigInteger(1, MessageDigest.getInstance("SHA1").digest(message.getBytes())).toString(16); } } endsubmit; quit; options set=classpath "%sysfunc(pathname(cp,f))"; data class; dcl javaobj sha1('Sha1'); do until (done); set sashelp.class end=done; length encoded_name $ 40; sha1.callStringMethod('encode', strip(name), encoded_name); output; end; run;

FriedEgg · ‎05-20-2015

@NG_Forest, It would be best to create a new post for you question as SHA1 and HMAC-SHA1 are significantly different topics. Also, I have posted on this subject previously, it does not use PROC GROOVY, as it did not exist at the time (the code in this post could be adapted to use is though): Using a macro to perform this type of task on every record in a file is really less than ideal. The better approach would be using the data step java object.

FriedEgg · ‎05-20-2015

, I'm glad to see you were finally able to get it working

Online Status	Offline
Date Last Visited	‎03-20-2026 07:25 PM