The methods listed above will not give you exactly that binary proportion, but very close to it. This is what I use to get almost exactly the desired proportion for 0/1.  The idea is to track the actual proportion generated so far and to "wiggle" the probability to compensate. %let prob1 = 0.2345; %let size  = 100000; data want;     if _n_ = 1 then do;      retain _need1 _remain;      _need1 = &prob1 * &size;    *  number of 1 needed, replace with a number if you like;      _remain = &size;            *  remaining number of records;     end;     do _i = 1 to &size;      x4 = ( ranuni( 12345 ) <= ( _need1 / _remain ) );      output;      if x4 then _need1 = _need1 - 1;     * if is 1, need 1 less 1;      _remain = _remain - 1;              * have 1 less record left;     end;     drop _remain _need1 _i; run; proc means; run; This generates exactly the desired proportion, almost without fail.  If you have an input dataset, try some variation of this: %let prob1 = 0.2345; data want;      set have nobs=_tot;      if _n_ = 1 then do;           retain _need1 _remain;           _need1 = &prob1 * _tot;         *  number of 1 records needed, replace with a number if you like;           _remain = _tot;                 *  remaining number of records;      end;      x4 = ( ranuni( 12345 ) <= ( _need1 / _remain ) );      if x4 then _need1 = _need1 - 1;     * if is 1, need 1 less 1;      _remain = _remain - 1;               * have 1 less record left;      drop _remain _need1; run;      Often this idea is used in sampling as well to get exactly the desired proportion.  A bit of work can extend it to stratified sampling.  Just have to keep more counters and adjust appropriately. ... View more

As the other posters have noted, this is a really bad data structure to work with, and is causing anyone that needs to manipulate data enormous headache.  Fixing the issue properly at source is the ideal solution, otherwise it will continue to be a maintenance nightmare.  Whoever created the output should be made to read it back in in order to appreciate the consequences of poor design.  Even if the data file can be changed to pure fixed position file, or a separator delimited file, there is still all of the existing instrumentation logfiles to deal with, so the problem doesn't go away entirely until the old files can be done away with. The core issue, if I understand your situation correctly, is that when fields go negative, instead of prepending a minus sign and dropping the right most digit, thus keeping the same field width (probably didn't want to lose the field precision), the program writes a minus sign followed by the same number of columns, thus widening the field by 1.  And this has happened at a few places in the file so far.  This is really nasty since each time it happens, it will shove all the following field by 1, thus the minus sign won't necessarily all occur at the same position except the very first field.  Approaches that scan for minus at pre-determined positions won't work well without enumerating all possible combinations. SAS is extremely flexible in reading data files, so there's always a way , though it becomes increasing complex and fragile, and require more skills to maintain and diagnose problems.  Here's a short program that illustrates an approach that should be helpful. This first data step uses fixed column input.  The first 2 records conform to the structure, and is read in OK.  All following records cause problems.  data out;     input f1 4. f2 4. f3 4. f4 4. f5 4. f6 4. ; cards; 0.1 0.2 0.3 0.4 0.5 0.6             OK 0.110.220.330.440.550.66            OK 0.11-0.220.330.440.550.66           f2 shifts by 1 0.11-0.220.33-0.440.550.66          f2, f4 each adds 1 0.11-0.22-0.33-0.44-0.55-0.66       f2, f3, f4, f5, f6 all adds 1 -0.11-0.22-0.33-0.44-0.55-0.66      everything is wider by 1 -0.11-0.220.33-0.440.55-0.66        ; NOTE: Invalid data for f4 in line 267 13-16. RULE: ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0 267 0.11-0.220.33-0.440.550.66 f2, f4 each adds 1 f1=0.11 f2=-0.2 f3=20.3 f4=. f5=440 f6=550 _ERROR_=1 _N_=4 NOTE: Invalid data for f3 in line 268 9-12. NOTE: Invalid data for f4 in line 268 13-16. NOTE: Invalid data for f5 in line 268 17-20. 268 0.11-0.22-0.33-0.44-0.55-0.66 f2, f3, f4, f5, f6 all adds 1 f1=0.11 f2=-0.2 f3=. f4=. f5=. f6=0.55 _ERROR_=1 _N_=5 NOTE: Invalid data for f2 in line 269 5-8. NOTE: Invalid data for f3 in line 269 9-12. NOTE: Invalid data for f4 in line 269 13-16. 269 -0.11-0.22-0.33-0.44-0.55-0.66 everything is wider by 1 f1=-0.1 f2=. f3=. f4=. f5=0.44 f6=-0.5 _ERROR_=1 _N_=6 NOTE: Invalid data for f2 in line 270 5-8. NOTE: Invalid data for f4 in line 270 13-16. NOTE: Invalid data for f6 in line 270 21-24. 270 -0.11-0.220.33-0.440.55-0.66 f1=-0.1 f2=. f3=220 f4=. f5=0.44 f6=. _ERROR_=1 _N_=7 NOTE: The data set WORK.OUT has 7 observations and 6 variables. Inspection of "out" shows the 3rd record is mis-interpreted as well even though there was no error messages.  Thus a mechanism to deal with these "occasionally 1 wider field" is needed.  Here's an approach, with the macro saving a tonne of repetitive typing. The macro, at the current column pointer, will attempt to read a variable "name" according to "fmt".  It checks the first position to see if it is a minus sign, if so, it will know it's -'ve, and input the following positions as "fmt".  If not, it will back up 1 position and read with "fmt". %macro read( name, fmt );     input _byte $char1. @ ;     if _byte ^= '-' then input +(-1) &name &fmt @ ;     else do;         input       &name &fmt @ ;         &name = - &name;     end;     drop _byte; %mend; data out1;     %read( f1, 4. )     %read( f2, 4. )     %read( f3, 4. )     %read( f4, 4. )     %read( f5, 4. )     %read( f6, 4. ) cards; 0.1 0.2 0.3 0.4 0.5 0.6             OK 0.110.220.330.440.550.66            OK 0.11-0.220.330.440.550.66           f2 shifts by 1 0.11-0.220.33-0.440.550.66          f2, f4 each adds 1 0.11-0.22-0.33-0.44-0.55-0.66       f2, f3, f4, f5, f6 all adds 1 -0.11-0.22-0.33-0.44-0.55-0.66      everything is wider by 1 -0.11-0.220.33-0.440.55-0.66        ; This code does read the input stream properly.  You can intersperse within your program like: input <known fields where this won't happen for sure> @ ;    *--- must hold line     ; @read( afrpf, 4. ) @read(  lbpf, 4. ) ... etc etc Or you might read all fields this way if they all have this possibility.  Hopefully this suits your needs and at least get you further along in dealing with this awkward data structure.  As other posters have said though, it really is best to fix the issue properly, although in reality, it will probably cost $$$ to re-write the instrumentation logging program and if you can deal with the data, then it won't get fixed.  Us poor buggers at the end of the chain has to suffer all of the poor design decisions made prior and clean up their messes. Message was edited by: Daymond Ling (typo fixes) ... View more

The PROC SURVEYREG documentation talks about using formatted value and using the ORDER= options on the SURVEYREG statement. You can do this two ways: - change the value in the dataset itself, or - use proc format tricks. e.g., your data is rece = '1','2','3','4', '4' would be used by default as you noted.  Suppose you want to use '3' as reference class, proc format;      value $race           '1' = 'A White'           '2' = 'B Black'           '3' = 'D Asian'           '4' = 'C Hispanic'      ; run; proc surveyreg order=formatted data=temp;      class race;     format race $race.;      ... '3' would be used as reference because its formatted value is sorted the highest. PROC SURVEYLOGISTIC, on the other hand, allows you explicit control over the reference class.  Here's a link to a paper showing examples http://www2.sas.com/proceedings/sugi31/140-31.pdf.  This is probably not supported by SURVEYREG though (I can't test at the moment). PROC SURVEYLOGISTIC DATA=ALL(WHERE=(20<=RIDAGEYR)) ; CLUSTER SDMVPSU; STRATA SDMVSTRA; CLASS SEX(ref='M') AGE1(ref=FIRST) RACE(ref='Non-Hispanic White'); WEIGHT WTMEC4YR; MODEL HIGHTC(EVENT='1') = SEX AGE1 RACE ; RUN; ... View more