I have following dataset which reading the output from a op command line and convert it into a sas dataset. It works in 9.2 but does not work in 9.3, Now I have a work around. But I would like to know why it does not in 9.3.
%let temp_lib_path=c:\temp;
%sysexec cd "&temp_lib_path";
option nonotes;
filename xlogcmd pipe "du ";
data lib_sum_draft;
infile xlogcmd
DLMSTR='./'
missover ;
input size dir_name $ ;
put _INFILE_;
run;
option notes;
but above code would not work, the size would be missing value in 9.3.
Can anyone let know why? what is the right way to have the size to be not missing?
You've got me curious. What is the system command "du"?
You've got me curious. What is the system command "du"?
sorry, I need to add more. I have cgywin installed so du is command disk usage.
my os is windows 7
Any warnings or messages in the log...
Is DIR_NAME also missing?
no, the dir_name is input correctly only the size is all set to missing.
I see he output of
size=. dir_name=/SAS_Scr _ERROR_=1 _INFILE_=89 ./SAS_Scripts _N_=1
Couple of questions. When you say it worked for 9.2, did it work for 9.2 on the same machine or another machine?
Paste your whole log, as it appears there has been an ERROR looking at _ERROR_ = 1.
Try input Size as char rather than num...
Barry
I have 9.2 and 9.3 installed on my work station and above code works in 9.2, I have the code working in 9.2 on another box first and then tried to run it on my box with 9.3 and it failed and then I tried it with 9.2 on my box and it still works. but failed in 9.3.
here is output log
89 ./SAS_Scripts
RULE: ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0
1 CHAR 89../SAS_Scripts 16
ZONE 3302254555676777
NUMR 899EF313F3329043
size=. dir_name=/SAS_Scr _ERROR_=1 _INFILE_=89 ./SAS_Scripts _N_=1
1824 ./sizing
2 CHAR 1824../sizing 13
ZONE 3333022767666
NUMR 18249EF39A9E7
size=. dir_name=/sizing _ERROR_=1 _INFILE_=1824 ./sizing _N_=2
264376 ./tmp2
3 CHAR 264376../tmp2 13
ZONE 3333330227673
NUMR 2643769EF4D02
size=. dir_name=/tmp2 _ERROR_=1 _INFILE_=264376 ./tmp2 _N_=3
16 ./tt
in the c:\temp, if I do "du"
it will output
89 ./SAS_Scripts
1824 ./sizing
264376 ./tmp2
16 ./tt
I did see _error_ is set to 1 but I do not know what cause it. From the log, you can see dir_name is set fine.
as I mentioned at begining, I have a work around , it is setting the size to be char as well,
if I do
input size $ dir_name $, it has no problem.
but this is not the case in 9.2
I have no idea, but am interested to find out what the answer is. Do you have time to compare the various system options you have set for 9.2 and 9.3. My guess is that at least one is different and I would definitely like to know which one could cause data to be skipped.
Looks like the du command is using tab ('09'X) as the delimiter between the number and the directory name. This is consistent with what I have seen from the unix command du.
RULE: ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0
1 CHAR 89../SAS_Scripts 16
ZONE 3302254555676777
NUMR 899EF313F3329043
2 CHAR 1824../sizing 13
ZONE 3333022767666
NUMR 18249EF39A9E7
Change your INFILE statement to use tab as a delimiter.
infile xlogcmd DLM='09'x truncover;
yes, it uses tab, how do you tell from the log? thank you very much.
Here I understand why 9.3 think it is error because it thinks the size is numeric but based on the delimiter defined, it thinks the size is not mumeric because of the tab as the char but did not know to remove that tab.
but 9.2 seems does not care and just load it perfectly using the dlmstr that I told it and truncate the tab from the size since I tell it the size is numeric. Not sure why 9.3 can not and wonder if there is a setting or option that I need to turn on or it just a spot where 9.3 is not as smart as 9.2 .
When SAS lists data to the log (as it does when it gets an error during an INPUT statement) it will show you.
If the line contains characters that are not normal printable characters then it lists the HEX code under each character. See the piece I copied from you posted log above. 09 is the hex code for a tab character.
You do not need to remove the tab, just let SAS know to treat it as a delimiter by using the DLM option on the INFILE statement.
If you really ran the exact code on 9.2 and 9.3 then the difference is in the actions of the du command and the two different machines.
Here is the code I would use to read the output of a du command.
filename du pipe 'du';
data du;
infile du dlm='09'x truncover lrecl=300;
input size dir $256. ;
run;
thank you. I used dlmstr='092E'x so that I would not need to change other code.
I really just run the exact code on 9.2 and 9,3 on the same machine and the one on 9.3 failed but not on 9.2. 9.2 knows to remove the tab even I did not define it as the delimiter. In fact the du from cygwin on windows runs always has a tab as delimiter no matter from any machine.
That doesn't look like the value for DLMSTR in your original program. Are you using the exact same program with 9.2 and 9.3 or is it a copy? Perhaps the tab character got removed or transformed. Try reading the program with a data _null_ step including the LIST statement to see if there is actually a tab character inside the quotes.
data _null_;
infile 'du_program.sas' ;
input;
if index(upcase(_infile_),'DLMSTR') then list;
run;
sorry, I did not make it clear. My original post is modified from the code I used. I add a / to try if it would works in 9.3 and ends up forgot to remove it.
dlmstr in the code I used does not have the /
I'm surprised the plain text for the value of that DLMSTR= actually worked. When using non-plain-text (you have a TAB character . dot and a /) I use and recommend hex.
Your first posting seemed to show the DLMSTR includes a / that looks (to me) like it belongs to a disk path, If you want to include that in the delimiter string then use
DLMSTR= '092E2F'x
I would not be surprised to hear that syntax handling of non-text stuff (and I would always consider TAB to be "not plain text") was "cleaned-up"
peterC
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.