There is actually several ways of doing this. Some maybe platform dependent. For example if your running on UNIX you could split the code in two sas programs and execute them separately (sas prog1.sas & and then sas.prog2.sas &) Or you could issue from SAS the X command with the NOWAIT option set (executes asynchronously), which is the same thing but started within SAS. Or (and this one, would be my favorite) if you want to control the threads from SAS (say, wait for both to end before proceeding with some other thing from SAS) and have the SAS/CONNECT licensed at your site, you could use the MP/CONNECT technique and submit both piece of codes each on a autosignon session. see: http://support.sas.com/rnd/scalability/connect/mp.html Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Actually, I think the data is correctly displayed... I suspect you have created the GENDER variable in the input dataset without preassigning to it, the maximum possbible length. You see, if you do not explicitly define a variable size, SAS will assume one of two things. If it is a numerical var, it will be defined with the maximum length, being 8 bytes. If it is a character var, it will be defined with the size of the first value assigned to it during execution. In your case, I suspect the first value assigned to GENDER was 'male' which is 4 bytes long. From there, all other values where truncated to that size. For example, data YOURDATA; GENDER='male'; output; /* first assignment defines variables size = 4 bytes */ GENDER='female'; output; /* truncated, GENDER='fema' */ GENDER='unknown'; output; /* truncated, GENDER='unkn' */; run; to avoid this explicitly define the variable size with the LENGTH statement. data YOURDATA; length GENDER $7; /* define GENDER as a 7 byte char variable */ GENDER='male'; output; GENDER='female'; output; GENDER='unknown'; output; run; Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Very confusing to me... Could you please detail the transformation?! Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Hello Fred. You could access to the metadata of the the table (say with proc contents or dictionary.columns), build a macro variable with the list of the desired columns and then perform a DROP of those (always rewriting the dataset). /* get table info */ proc contents data = YOURDATA out = _CONTENTS noprint; run; /* buil DROPLIST */ %let DROPLIST=; data _null_; set _CONTENTS; where index(upcase(NAME),'VO'); /* Var names who contains 'VO' */ call symput('DROPLIST',catx(' ',symget('DROPLIST'),NAME)); run; /* rewrite the dataset and drop the desired Vars */ %put &DROPLIST; data YOURDATA; set YOURDATA; drop &DROPLIST; run; Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

I agree with Patrick, generating many datasets are not a good thing to do (it should be "neater" if you could process the dataset at once without splitting it), but here's an "ugly" (call execute) but simple way of doing it without the complexity of macro coding. Assuming that Trip is ordered by PersonID and TripID: data _null_; set Trip; retain _FIRSTOBS; by PersonID TripID; /* assume that Trip is ordered */ if first.TripID then do; /* first pair */ _FIRSTOBS=_N_; /* hold the obs num */ _COMBNUM+1; /* count combination number */ end; if last.TripID then do; /* last pair */ call execute('data COMB'!!cats(put(_COMBNUM,best.))!! '; set x (firstobs='!!cats(put(_FIRSTOBS,best.))!!' obs = '!!cats(put(_N_,best.))!!'); run;'); /* slice the dataset with call execute call */ end; run; Caution, at the end you'll have many COMBx datasets (one per combination). Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

If I got this right, you should RETAIN variable X. Retain, holds the value of the previous iteration. Assuming that table1 holds the input data. data table2; set table1; retain X 0; /* explicit retain for the X variable */ X=X+Condition; run; or simply: data table2; set table1; X+Condition; /* implicit retain for the X variable, when using RETAIN_VAR+ */ run; Both are the same. On the latest, there's no need to explicitly use the retain statement. Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Scott is right, to add 1 day, you just need to increment the DATE variable by 1. But, I think Main is having trouble to advance one month (quote: "...but the day diff from one month to anoher"), so in this case, INTNX would be the most simple way of doing it. Cheers from Portugal. Daniel Santos at www.cgd.pt ... View more

To increment a date value use the INTNX function. See: http://support.sas.com/documentation/cdl/en/lrdict/61724/HTML/default/a000212700.htm Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Very strange behavior... I'm not aware that a file can only be shared on a single job/target table... Unless there is some kind of file lock issue, but both jobs are acessing the file for read access, right? On what kind of system is the workspace server running? Which version of DIS are you running? Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Hello guys. DICTIONARY.COLUMNS would be the most simple and straightforward way. I still prefer the PROC CONTENTS procedure, since when using it intensively (many columns, many tables) it is a lot more fast against the querying DICTIONARY tables method. I think this will do what you need: proc contents data = A out = _A_CONTENTS noprint; run; /* only necessary if you need to maintain the column order */ proc sort; by VARNUM; run; /* load NAMEs to myPredictors macro */ %let myPredictors=; data _null_; set _A_CONTENTS; /* build myPredictors list with NAMES separated by space char */ call symput('myPredictors',catx(' ',symget('myPredictors'),NAME)); run; /* result */ %put &myPredictors; Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

You could try this also: data _null_; S='AAAA AAAA AAAA AAA AAAAA AAAAAA, AAAAA AAAA AAAAAAAAAAAAA BBB BBBBB BBBBB BBBBB BBBBBB BBBBB BBBBBBB BBBBBBBBBBBB CCCCCCC CCCCC CCCCCCC CCCCCCC CCCCC CCCC CCCCCCCCCC DDDD DDDDD DDDD DDDDDDD DDDDD DDDDDDDD DDDD DDDDD DDDDDD DDDDD DDDD'; I1=1*55+index(substr(S,55),' ')-1; /* 1st split starting at 55 */ I2=2*55+index(substr(S,2*55),' ')-1; /* 2nd split starting at 2x55 */ I3=3*55+index(substr(S,3*55),' ')-1; /* 3rd split starting at 3x55 */ VAR1=substr(S,1,I1); VAR2=substr(S,I1,I2-I1); VAR3=substr(S,I2,I3-I2); VAR4=substr(S,I3); /* result */ put VAR1=; put VAR2=; put VAR3=; put VAR4=; run; Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

If &DATE resolves to 17998, there's no conversion needed, just the appropriate format. Just X=&DATE will do the job. Actualy DATE9. is a numeric format. 17998 and '11APR2009'd are the same. To see X as DATE9, just apply the format DATE9. to the X, or use formatted print (put X date9.;) For example: data _null_; X=17998; put X date9.; run; and you will see the NUMERIC value 17998 formated with the NUMERIC format date9. Hope it helps. ps: btw the call resolve("&DATE") is useless "&DATE" just will do. Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Hello. Using the appropriate SAS functions (it will work on any system): data FILENAME_LIST; length FILENAME $200; drop _:; /* drop temporary variables */ _RC=filename('dirref',"D:\Temp"); /* assign dir ref */ _DID=dopen('dirref'); /* open dir */ _NUM_OF_FILES=dnum(_DID); /* get total number of members */ do _I=1 to _NUM_OF_FILES; /* cycle through members /* FILENAME=dread(_DID,_I); /* read member name */ output; end; _RC=dclose(_DID); _RC=filename('dirref'); run; FILENAME_LIST will contain a row per file in the specified directory. Another way could be piping the result of a list command (system dependent) into a dataset. Something like that (Windows example based on dir command): filename FILELIST pipe "dir /b"; data FILENAME_LIST; length FILENAME $200; infile FILELIST; input; FILENAME=_infile_; run; From here you just have to select the desired filenames (say with a approriate wildcard), assign those to macro variables and use the latest on your SAS script. Greetings from Portugal. Daniel Santos at www.cgd.pt Message was edited by: Daniel Santos ... View more

Hi guys. Here's another solution. If your not concerned about the final order of the rows, try this: data OUT; set IN (firstobs=2) end=_EOF ; /* first set starts at 2nd row */ if _EOF then do; /* deals with last row */ C=0; output; end; C=B; /* stores value of B into C */ set IN; /* second set starts at 1st row */ output; run; this results in: a b c 1 23 15 2 15 45 3 45 55 5 67 0 4 55 67 result is as expected, but the last row positions is switched with the previous. Greetings from Portugal. Daniel Santos at www.cgd.pt ... View more

Linus is correct, I also think there's no direct way to mimic the NODUPKEYS feature of PROC SORT in SQL. One way could be: proc sql noprint; create table NODUPKEYS (drop = _N) as select T1.* from (select monotonic() as _N, * from A) as T1, (select monotonic() as _N, count(CUST) from A group by CUST) as T2 where T1._N = T2._N ; quit; The monotonic() function here, is used similarly as the automatic variable _N_ (try to run the two selects for T1 and T2 separately to see the results of monotonic()). But it always involves remerging the data with some stat table (in the example T2). So I guess it will be always much more "messy", complex and inefficient than the SORT NODUPKEYS options. Greetings from Portugal. Daniel Santos at www.cgd.pt Message was edited by: Daniel Santos ... View more