Were you able to figure this out?   I suspect the CLASSPATH isn't including your class.  There is information on setting the CLASSPATH here:   https://go.documentation.sas.com/?cdcId=pgmsascdc&cdcVersion=9.4_3.4&docsetId=lrcon&docsetTarget=n0swy2q7eouj2fn11g1o28q57v4u.htm&locale=en#n1kystna6h6qxon1323zlbz80gwk ... View more

Are you a SAS programmer??  (Of course you are!)   Come see DATA step run in multiple threads across multiple machines in SAS Viya.  Or, the new varchar type in SAS Viya.   Don't know what SAS Viya is?  Once you see DATA step running there, you'll understand right away!!     DATA Step in SAS® Viya™: Essential New Features  (Wednesday - 11am)   Programmers, this is your invitation to come by the Programming area in the Quad and say "Hi!"  If you don't program, there are other areas of the Quad for you.     ... View more

My prior post isn't entirely correct. For instance, you do not need the %STR around the regular expression. And, there is a difference in behavior in macro between SAS 9.2 and earlier versions of SAS. Given that I'm the world's worst macro programmer :-), I had a side chat with the developer for macro and Toby to educate me on what's happening with this seemingly simple example. Here is a better analysis of this situation: (1) The original code shouldn't put single quotes around the regular expression because macro passes the single quotes to PRXCHANGE, which causes a PRXCHANGE error. [pre] %put New String: %sysfunc(prxchange('s/ old / NEWER /oi',-1,' new and old ')); [/pre] Should be: [pre] %put New String: %sysfunc(prxchange(s/ old / NEWER /oi,-1,' new and old ')); [/pre] (2) On SAS 9.1.3, this code causes an error. On SAS 9.2, this code works fine. In SAS 9.1.3, the macro processor sees PRXCHANGE could have a numeric or character first argument and it sees the / in the first argument, so it attempts to evaluate the first argument as a numeric expression. This results in an error, an error is output to the log, and a zero length string is passed to PRXCHANGE. PRXCHANGE then outputs an error because an invalid pattern was passed to it. In SAS 9.2, the macro processor was modified such that if the numeric evaluation fails, it assumes the value must be a character value and the character value is passed to PRXCHANGE. At this point, folks with SAS 9.2 are happy. What should folks with SAS 9.1.3 do? I see two solutions: (2a) Change the regular expression delimiter from / to a non-arithmetic character, like !. [pre] %put New String: %sysfunc(prxchange(s! old ! NEWER !oi,-1,' new and old ')); [/pre] (2b) Have a three statement program that uses PRXPARSE and PRXFREE. [pre] %let re = %sysfunc(prxparse(s/ old / NEWER /oi)); %put New String: %sysfunc(prxchange(&re,-1,' new and old ')); %syscall prxfree(re); [/pre] This solution works because PRXPARSE only accepts a character argument, so no numeric evaluation is attempted. (3) The original code has single quotes around the string to be modified. If the result shouldn't have single quotes, the %STR macro function can be used to preserve leading and trailing blanks. [pre] %put New String: %sysfunc(prxchange(s! old ! NEWER !oi,-1,%str( new and old ))); [/pre] Does this make sense? Jason ... View more

I believe that everything is work as it should. However, the need to quote certain characters in Macro with Macro quoting functions is different than how quoting works in DATA step. This post will discuss three items: (1) The valid delimiter charaterse that delineate parts of a regular expression. (2) How to get / working as a delimiter with %SYSFUNC. (3) How to use PRXDEBUG to see the regular expression PRXCHANGE is passing to Perl. The delimiters for a Perl regular expression can be any non-alphanumeric character. So, using ! or ' or | are valid delimiters. The most common delimiter is /, however feel free to use the delimiter that works the best for your situation. In the case of Macro, using ! may be easier is most situations because it doesn't require Macro quoting. Now, how do we use / as a delimiter from %SYSFUNC? In the original %PUT code: [pre] %put New String: %sysfunc(prxchange('s/ old / NEWER /oi',-1,' new and old ')); [/pre] The regular expression given to PRXCHANGE is 's/ old / NEWER /oi', including the single quotes. PRXCHANGE treats the single quotes as the delimiter and since there isn't anything after the second delimiter, it complains that there isn't any replacement text. The way strings are passed to functions from Macro is different than in DATA step. Toby hints at how to quote the regular expression with %STR(). To get this code to work with / as the delimiter, wrap the regular expression with %STR(), as in this example: [pre] %put New String: %sysfunc(prxchange(%str(s/ old / NEWER /oi),-1,' new and old ')); [/pre] To debug this problem, PRXDEBUG could have been used to see the regular expression that Perl received from the PRXCHANGE. Here is an example showing how to use PRXDEBUG from DATA step and Macro. In the DATA step case, notice that the pattern being searched for is ` old ' while in the Macro case it is `s/ old / NEWER /oi'. In the Macro case, the search string is literally "s/ old / NEWER /oi", indicating an unintended search pattern is being given to Perl. While the PRXDEBUG output isn't the most elegant, it may help point out a problem . [pre] 20 data _null_; 21 call prxdebug(1); 22 NewString=prxchange('s/ old / NEWER /oi',-1,' new and old '); 23 put NewString=; 24 run; Compiling REx ` old ' size 4 first at 1 1: EXACTF < old >(4) 4: END(0) stclass `EXACTF < old >' minlen 5 Matching REx ` old ' against ` new and old ' Setting an EVAL scope, savestack=0 8 <new and> < old > | 1: EXACTF < old > 13 <new and old > <> | 4: END Match successful! Match failed NewString=new and NEWER 25 26 %let one=1; 27 %syscall prxdebug(one); 28 %put New String: %sysfunc(prxchange('s/ old / NEWER /oi',-1,' new and old ')); Compiling REx `s/ old / NEWER /oi' size 7 first at 1 rarest char W at 11 1: EXACT <s/ old / NEWER /oi>(7) 7: END(0) anchored `s/ old / NEWER /oi' at 0 (checking anchored isall) minlen 18 ERROR: The routine PRXCHANGE was called using a regular expression that contains no replacement text. ERROR: An error occurred while executing function PRXCHANGE referenced by the %SYSFUNC or %QSYSFUNC macro function. [/pre] I hope this helps. Jason ... View more

Two ways come to mind for how to do this. One is to use an array of the asset variables, then use the value in the month variables to index into the array. Another way to do this is to construct a variable name as a string, then call the VVALUEX function to get the value of that variable. The array solution is probably the most efficient, yet you may have be crafty with defining the upper and lower bounds of the array. Both of these methods are shown at the bottom of this post. A link to the doc for VVALUEX is here: http://support.sas.com/documentation/cdl/en/lrdict/63026/HTML/default/viewer.htm#/documentation/cdl/en/lrdict/63026/HTML/default/a002233818.htm [pre] /* Create sample dataset */ data info; input ID (assets0908 assets0909 assets0910 assets0911) (:comma.) (month1 month2 month3) ($); datalines; 1 $109 $200 $150 $190 0909 0910 0911 2 $40 $20 $10 $5 0908 0909 0910 ; /* Use month to index into ASSETS array */ data sums(keep=id asset_sum); set info; array assets[0908:0911] assets:; array month month:; asset_sum = 0; do j = 1 to dim(month); month_num = input(month , BEST12.); asset_sum + assets[month_num]; end; run; /* Sum variables that are specified in the MONTH1-MONTH3 variables * (1) Construct variable name and place in ASSET_VARNAME * (2) Call VVALUEX and pass ASSET_VARNAME to get value of asset variable * (3) Convert character value returned by VVALUEX into a numeric value. * (4) Accumulate numeric value into ASSET_SUM */ data sums2(keep=id asset_sum); set info; array month month:; asset_sum = 0; do j = 1 to dim(month); asset_varname = 'assets' || left(month ); asset_value = vvaluex(asset_varname); asset_sum + input(asset_value, best32.); end; run; proc print data=sums; run; [/pre] Output: [pre] Obs ID sum 1 1 540 2 2 70 [/pre] ... View more

The "K" functions can be used to manipulated strings where a character may take more than one byte. For instance, you could use KLENGTH to get the length of the string, then pick characters out of the string with KSUBSTR in a loop. A log snippet showing this is at the bottom of this post. Jason [pre] 19 data _null_; 20 text = 'abcdef'; 21 do i = 1 to klength(text); 22 c = ksubstr(text, i, 1); 23 put c; 24 end; 25 run; a b c d e f [/pre] ... View more

Here's a small program that works with the sample data and code you provided. I removed the FORMAT statement for sh_date1 since this variable is dropped. I don't call the STRIP function. If you see blanks where you expect a valid date, it could be that you're working with a missing value, which might result from an invalid date. [pre]data ship_dates; length ship_date $ 10; input ship_date; sh_date1 = input(ship_date, anydtdte10.); sh_date2 = put(sh_date1, mmddyy10.); drop ship_date sh_date1; rename sh_date2 = ship_date; datalines; 9/1/2009 10/27/09 09/10/2009 ; proc print data=ship_dates; run; [/pre] Output: [pre] Obs ship_date 1 09/01/2009 2 10/27/2009 3 09/10/2009 [/pre] ... View more

Even though the duplicate: initialization option isn't available in SAS 9.1.3, you can load the hash object with the last obs from a group of duplicate keys. To do this, use the REPLACE method. Here is a small program: [pre] data a; input key a b c; datalines; 1 10 100 9 1 20 200 8 2 20 100 8 3 30 100 9 4 40 100 9 4 20 200 8 ; data _null_; if _N_ = 1 then do; declare hash H(ordered:'d'); H.definekey('key'); H.definedata('a','b','c'); H.definedone(); /* Load the hash object, getting last obs when there */ /* are duplicate keys. */ do while (^done); set a end=done; H.replace(); end; end; rc=H.output(dataset:"work.out"); stop; run; proc print data =work.out; run; [/pre] ... View more

If START_DATE and END_DATE are character values, those need to be converted to numeric SAS date values before calling DATDIF. One way to convert a character value to a numeric value is to use the INPUT function. Here is a small program that uses the INPUT function and the YYMMDD. informat to convert character date values into numeric date values. [pre] data in; start_date = '20100201'; end_date = '20100204'; output; run; proc sql; create table out as select datdif(input(start_date, YYMMDD8.), input(end_date, YYMMDD8.), 'ACT/ACT') as datdif, start_date, end_date from in; quit; [/pre] ... View more

Another solution is to use the FILEVAR= option on the FILE statement. When writing to files on disk, FILEVAR= enables you to write to several files from one DATA step. The same is true when using FILEVAR= with DDE. It enables you to process several DDE commands from one DATA step. Here is an example where Sheet1, Sheet2, and Sheet3 are filled with two columns and 10 rows of dummy data: [pre] data _null_; do i = 1 to 3; sheet = cats('excel|[test-sheet.xlsx]Sheet', i, '!r1c1:r10c2'); file area dde filevar=sheet; do x = 1 to 10; y = 2*x; put x y; end; end; run; [/pre] To me, this solution is simpler because there aren't any macros or macro variables involved. Documentation for FILEVAR= option on FILE statement: http://support.sas.com/documentation/cdl/en/lrdict/62618/HTML/default/a000171874.htm#a000699156 ... View more

Data organization should be given critical thought when designing a solution. The way data are arranged will affect the complexity of the implementation and performance. Views provide a mechanism for rearranging data without replicating them on disk. When different applications rely on the same data, yet each implementation would prefer a different layout, views often provide a sufficient solution. -- Jason Secosky, SAS R&D / DATA Step ... View more

Ashutosh, let me show what SAS can do then we'll discuss what it can't. The DROP= data set option and DROP statement support variable lists to drop a set of variables. For instance, to drop all the variables from an output data set that begin with the prefix "X" one would code: [pre] DATA OUT( DROP=X: ); [/pre] To drop the variables X1 through X10, one would code: [pre] DATA OUT( DROP=X1-X10 ); [/pre] Variable lists work in many situations where a programmer would like to drop an array of variables. The situation where variable lists break down is when an array of variables do not have a common prefix. As in: [pre] ARRAY A X Y Z; [/pre] In this case using DROP=X--Z may drop X, Y, and Z. I say may because if the variables aren't ordering in the PDV as X, then Y, then Z, the variables you think you're dropping will not be dropped. I'd rather code DROP=X Y Z than use X--Z because maintaining a variable ordering in the PDV can be tricky and obfuscate the code. If you have a situation where variable lists don't work well, a workaround is to place the array variables in a macro variable. As in this code: [pre] %let ArrayVars = x y z; data out(drop=&ArrayVars.); array a &ArrayVars.; set in; run; [/pre] This program will create an array consisting of the variables X, Y, and Z and will drop them from the output data set. The reason arrays aren't supported with the DROP= or KEEP= option is that the options are not processed by the DATA step. Rather, they are processed by the engine that is used to read or write the data set. The engine is aware of the variables to be read or written, so it can drop or keep them. The engine is not aware of DATA step arrays, so it would not recognize a name as an array. The separation between the DATA step and the engine is what keeps DROP= or KEEP= from handling arrays. -- Jason Secosky, SAS R&D / DATA Step ... View more

My suggestion is similar to Jack's. Either use PROC SQL to copy the data sets or PROC DATASETS. Both of these are data set oriented languages, so they don't have as many constraints as the DATA step. When PROC DATASETS copies a data set, it will maintain the sort assertion in the copy along with indexes and integrity constraints. The DATA statement creates a brand-new data set. With a brand-new data set, there are no special attributes defined on it, unless the programmer specifies them with data set and/or system options. The main reason is so the DATA statement operates the same for all DATA steps. That is, if the DATA step were to have more than one statement, it becomes unclear which attributes of an input data set apply to an output data set. A program may read from more than one input data set or may modify variables which change their sortedness. In these cases, it is difficult to determine which attributes apply to an output data set. And, the attributes that apply may be specific to the data being processed. Let's look at JonT's situation. After PROC SORT sorts a data set, a sort assertion is set on the data set. Before PROC SORT sorts a data set, it checks the sort assertion. A sort is not performed if the sort BY variables are the same as the sort assertion. A sort is performed if there is no sort assertion or if the sort assertion is different than the sort BY variables. In JonT's case, after using a DATA step to copy the data set, there would be no sort assertion set, so PROC SORT would resort the sorted data. There are some related changes coming. In SAS 9.2, PROC SORT will have options to validate the sort order of a data set and set a sort assertion if the data set is sorted. The cost is a sequential pass through the data without the expense of sorting. We are investigating solutions that would avoid a sequential pass through the data. Until then, I would investigate a PROC SQL or PROC DATASETS solution. SAS Technical Support ( http://support.sas.com/techsup/contact/index.html ) can provide assistance with these PROCs, if necessary. -- Jason Secosky, SAS R&D / DATA step Message was edited by: JasonS@SAS at Apr 4, 2006 10:16 AM ... View more