why this does not work in 9.3 but works in 9.2

[kwu]

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?

[art297 · Accepted solution]

You've got me curious.  What is the system command "du"?

[kwu]

sorry, I need to  add more. I have cgywin installed so du is command disk usage.

my os is windows 7

[twocanbazza]

Any warnings or messages in the log...

Is DIR_NAME also missing?

[kwu]

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

[twocanbazza]

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

[kwu]

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

[art297]

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.

[Tom]

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;

[kwu]

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 .

[Tom]

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;

[kwu]

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.

[Tom]

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;

[kwu]

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 /

[Peter_C]

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