I think it already does. Just the rows in WANT are sorted differently from your example. Is that a problem?     ... View more

There is a thorough discussion on the topic in the SAS online docs called Numerical Accuracy in SAS Software. In my view a must-read for every SAS user.   Regards, - Jan. ... View more

Hi,   How about this:   data want; do v3r=0.1 to 1 by 0.1; do p=1 to nobs; set have point=p nobs=nobs; if not missing(v3) then v3=v3r; output; end; end; drop v3r; stop; run; You basically loop through dataset HAVE and replace r3 with the value according to your rule. The STOP is important or your datastep will loop forever (or until some resource gets exhausted).   Dataset WANT has some pattern also that could be applied to the code also alleviating the need for WANT. But that's not your question.   Hope this helps, - Jan.   * Edited to use NOBS= ... View more

This is weird. Your formats look like predefined ones. his can happen if the assumption about the datatype is wrong. A reference to a numeric format associated to a charcater variable can get prepended with a $, leading to a not-found message but I wonder if that's the case here.   Can you provide a proc contents and ssome sample records of the input dataset? Also the actual log contents would be helpful.   Worst case you have an issue with your SAS installation. What directories make up your SASHELP library?   A simple test can tell a lot. Please run:   data _null_; d='21JUL2016'd; put d= mmddyy10.; run; The expected result would be: d=07/21/2016   Regards. - Jan. ... View more

In your case you can revert the FIRSTOBS option to its default by   OPTIONS FIRSTOBS=1; Deleting an OPTIONS statement does not undo its effects unless you restart SAS. Usually this option is used in a more limited scope that in your case so there is less need to worry about the remainder of the code.   Hope this helps, - Jan.  ... View more

Hi,   Use   if death=0 then obs_fn="30JUN2015"d; If the condition is not met the variable will get the missing value.   Also I notice you have adopted the solution of @atul_desh to your initial question. Although correct it is also unnescecariliy complicated and waistful. I suggest you use the much simpler "30JUN2015"d notation instead.   The line if death=0 then ; is not syntactically incorrect, it just does nothing. In this case the semicolon is interpreted as a NULL statement. Therefore the value is assigned to all rows instead of to just the ones you were hoping it would.   Hope this helps, - Jan. ... View more

To elaborate on your embedded second question:   ... format obs_fn yymmddn8.; obs_fn = 20160630; run;   The new variable "" appears as 9999-12-31   I am not sure what I have done wrong.   SAS stores dates internally as an integer enumerating the number of days since (or up to) January 1st, 1960. You have assigned the integer value 20160630 to your date value. This is then interpreted as 20160630 days since 01JAN1960, apparently being so high that we reach the end of the current 10.000 year period (10 kilo annum), 31DEC999.   Hope this helps, - Jan ... View more

I ansered this in your other post. Somehow this got posted twice:   SAS has the concept of the date literal. Just write the desired date in DATE9. forat between quotes and a trailing d:     obs_fn = '30JUN2016'd;   ... View more

SAS has the concept of the date literal. Just write the desired date in DATE9. forat between quotes and a trailing d:   obs_fn = '30JUN2016'd; That should do the trick.   Similar notations are available for time, datatime hex, etc.   Hope this helps, - Jan. ... View more

This makes me curious to find out what the input file looks like from the SAS perspective.   Could you execute this piece of code and share the results?   filename foo ZIP '/applocation/kg/label_categories.csv.zip' member="label_categories.csv" ; data _null_; infile foo obs=10; input; put _infile_; run;   This dumps a piec of your unzipped file to the log. That may help understand the behaviour of proc import.   Regards, - Jan.       ... View more