All of my testing with SAS 9.1.3 PC and SAS 9.2 Unix shows length statement working properly.  Of course, the length statement needs to be at the beginning of the data step prior to the set statement. I am at a loss to understand why it wouldn't work without seeing the actual program and logs. ... View more

data tbl ;     length id 8 ;     set tbl_ ;     by num ;        retain id 0 ;     if num = . then id = .;     else if first.num then id + 1 ;    run ; Output on first column as input: .       . .       . 10     1 10     1 20     2 20     2 20     2 30     3 30     3 30     3 30     3 But is there any difference between using NUM or ID as ID field?  The only difference is that ID is sequential, but if you only need them as keys, then there's really no difference. ... View more

Here's an idea to try out as well.  If the data occurs in very specific blocks in a predictable pattern, then this structure may work: data want;      infile in (with all suitable options like line length truncover...);      input @;                                         *--- read the line into _infile_ buffer;      if left( _infile_ ) =: 'Daily Report' then do;                    *--- skip the report headers;           do i=1 to 9;   input;   end;     *--- swallow 9 lines;           return;      end;      acct = substr((left,_infile_),1,7);      if verify(acct,'0123456789') = 0 then do;           input #1 acct : 7. company_name db_cr_amount dt_appr                  #2 .....                  #3 .....                  #4 .....                  #5 .....                  #6 .....                  #7 .....           ;           output;    end; run; The idea is to read a line & hold it, figure out if it is the start of a known block, if it is not the start of something useful, do nothing with it, start next loop. If it is the start of a known block, then handle that known block as appropriate. The "return" statement can be used to "start the next iteration of the data step". Too bad you have to work with this data structure, it's far easier if you can arrange with them to give you the CSV file or XML file or Excel file even.  Anything structured is better than having to "undo" the report formatting. ... View more

There's no need to hunt for the correlation.  It is generated through this process: Generate two separate random normal variables.  call them x1, x2. If you want "drawn from a population with correlation R", skip this.  If you want the drawn sample to have correlation R, then do this step:  put the two columns through principle components (PROC PRINCOMP or PROC FACTOR) to generate two factors that are completely uncorrelated.  The reason is that x1, x2 from above might have non-zero correlation. Use this formula:  Y = x1 * R + x2 * sqrt( 1 - R**2 ).  Y will be correlated with x1 with exactly correlation R. For more variables, in general, take the components matrix and post multiply by Cholesky decomposition of R, the correlation matrix. %let r=0.5; data test;     call streaminit( 123 );     do i = 1 to 1000;         x1 = rand('normal');         x2 = rand('normal');         output;     end;     drop i; run; proc princomp data=test out=pc;     var x1 x2; run; data test1;     set pc;     yr =    x1 * &r +    x2 * sqrt( 1 - (&r)**2 );     yp = prin1 * &r + prin2 * sqrt( 1 - (&r)**2 ); run; proc corr;     var x1 x2 yr prin1 prin2 yp; run; ... View more

Yes, you're right, the more weighty observations carries more, ahem, weight, in the analysis    Weighted means, weighted variances, weighted parameter estimates, and so on... Details on how its used in each PROC is in the PROC documentation. ... View more