Should be easy to fix. Search for the \ character in the code. Then fix the places where it is doing it wrong. To scan filenames just go ahead and use all three characters /.\ as the delimiters. That way it will work on both Unix and Windows file systems.
You might also need to check that the case of the filenames it is checking match what it is checking. So if your actual files on the unix drive end with .AWC and the code is looking for filenames that end with .awc then adjust the code so it matches what it should.
If you want to improve the code then change the logic so it instead makes a dataset with the list of files. You can use something like this macro to do that. https://github.com/sasutils/macros/blob/master/dirtree.sas
Then use that dataset to drive the logic for reading the files. Logic structure will look something like this:
data ... ;
set dirtree;
where upcase(scan(filename,-1,'.'))='AWC';
do while(not eof);
fullname=catx('/',dname,filename);
infile dummy filevar=fullname truncover end=eof;
input ....
....
output;
end;
run;
Are you able to open the .awc files in a text editor like Notepad? Just to see if there's data there? I assume these are just plain text ascii files. I don't really understand why there's the insane level of validation the program is doing on the file names. Seems like the program would be much more straightforward if it just expected an actual list of validated file names from the user. In any case, it seems like for some reason, the program is stopping at this STOP statement because it doesn't like the input file. I would first verify that that's the case by creating a blank line above the STOP line and adding this:
put "stopped reading at " currfile;
(be sure to include the semicolon). Then re-run and search the log (yes, Cntrl-F) for "stopped reading" -- the first one you find will just be the code itself, but there should be a 2nd occurrence too that is followed by the actual .awc file name it was trying to read. Something about the following logic is causing it to stop.
I did as you mentioned.
Attached is a screen shot of the second "stopped reading". It is at the very first file of the bunch. But they all similar.
So first fix the place where it is trying to get the sequence number from the filename. In your LOG it was line 241
seqn = scan(currfile, -2, '\./');
Then I would just comment out the whole section that was trying to ignore the none AWC files. Instead just make sure the folder you pointed to only has the files you want to read. In your log that was lines 244 to 271 . So make line 243 contain /* and line 272 contain */ and then lines 244 to 271 become one long block comment.
Hey,
It seems everything is going well, and all the data appears to be in the output, and data is being analyzed, so that is great!
But the next step would be to get everything out into Excel files. I am unsure how to do this. I have attached the log just in case any thing is clear there as to why. The files that come out in the reports folder, as the code dictates, are .xls.bak. So when I download it, they do not open in Excel.
I have also attached a picture of the file directory to depict it better. Please let me know what output I am getting.
Again, thank you so much for your time!
What do you want to put into the EXCEL files.
From your picture you have 4 SAS datasets. Do you want each one it is own EXCEL file?
If so just run some PROC EXPORT steps. Tell it which dataset to read in using the DATA= option and where to put the XLSX file using the FILE= option.
So if you pointed the MYLIB libref to the folder that has perday.sas7bdat in it then you could create an XLSX file using code like this.
proc export dbms=xlsx data=mylib.perday
file='/home/xxxx/foldername/perday.xlsx' replace;
run;
Not sure what the "summary" is. Are you talking about one of the datasets in your screen shot? Some REPORT that the code you ran produced?
If you want the reports to be EXCEL files instead of PDF files then you might want to add ODS EXECL command at the appropriate place in the code.
Personally I would split that large program into parts so you can run the step that converts the text files into SAS datasets with one program. Then have the other steps in the program start from the SAS datasets and produce the other things you need from that. So you don't have to keep rebuilding the SAS datasets to do other things, like generate EXCEL files.
It's finally time to hack! Remember to visit the SAS Hacker's Hub regularly for news and updates.
Use this tutorial as a handy guide to weigh the pros and cons of these commonly used machine learning algorithms.
Find more tutorials on the SAS Users YouTube channel.