Hi,
I am hoping someone can help. I am running SAS Enterprise guide on a Unix server. I have a very basic infile statement:
data profile;
infile "/SAS/data/nBOL/lookups/XXX.txt" dlm = "," pad missover dsd firstobs=2;
input key_customer :12.
key_user :$5.;
Keep = 'Yes';
run;
When I run the code via enterprise guide I see the following log:
"
NOTE: The data set WORK.PROFILE has 63377 observations and 3 variables.
"
i.e.NOT a blank file
when I run the code via a shell script in unix, the log presents as follows:
"
The data set WORK.PROFILE has 0 observations and 3 variables.
"
later on there is a reference to the dataset created and I get the following error when executing a proc sql where I join the infiledataset and then later try to reference the created dataset from the proc sql step.
"
NOTE: PROC SQL set option NOEXEC and will continue to check the syntax of statements.
NOTE: Statement not executed due to NOEXEC option.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE SQL used (Total process time):
.......
ERROR: File WORK.XXXPROFILE.DATA does not exist."
Does anyone know what is happening and how to get it to run and import properly?
Edited to Add: I am not an administrator and have very low level rights so I cannot change things on the server itself.
Other differences might be:
Doesn't seem like these should affect the program you shared though.
When running in EG, is the SAS session using your same Unix account with same user/group permissions?
Running PROC OPTIONS in each environment and comparing the results might be a good place to start.
Is there any ERROR info in your LOG ?
or try option truncover and termstr=
data profile;
infile "/SAS/data/nBOL/lookups/XXX.txt" dlm = "," truncover dsd firstobs=2 termstr=crlf;
data profile;
infile "/SAS/data/nBOL/lookups/XXX.txt" dlm = "," truncover dsd firstobs=2 termstr=lf;
Thanks for the input - tried both options and no luck. No actual error is shown, hence the confusion - Its hard to pin point what the issue is 😞
Make sure this SAS code is created under UNIX ,not Windows .
WORK.XXXPROFILE.DATA is different from WORK.PROFILE. Even if the import did not read any observations, you would still have the empty dataset.
You might have a problem earlier in your code when you run it in batch that causes SAS to set OBS=0, so you need to read the whole log from top down and eliminate all extraneous NOTEs, all WARNINGs and all ERRORs one by one.
The best method to run programs created in EG in batch is to use the BatchServer/sasbatch.sh script from the application server context you use in EG, as that provides an identical environment.
Other differences might be:
Doesn't seem like these should affect the program you shared though.
When running in EG, is the SAS session using your same Unix account with same user/group permissions?
Running PROC OPTIONS in each environment and comparing the results might be a good place to start.
EG sets OPTIONS VALIDVARNAME=ANY, which might affect import steps that read inputs with nonstandard column names.
I tested the code stand alone, outside the rest of my script and did see that the issue was infact linked to the VALIDVARNAME=ANY option above - I am still looking into ways to *not* apply that option (for other portions of the code where field names dont conform to SAS standard names), but thank you for helping me identify the issue!
Here's a very simple program. Run it in both environments, and hopefully the results will give you some insights into what's happening.
Tom
data profile;
length InRec $32767;
infile "/SAS/data/nBOL/lookups/XXX.txt" lrecl=32767;
input;
InRec = _infile_;
if _n_ = 5 then
stop;
run;
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!
What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.
Find more tutorials on the SAS Users YouTube channel.