topic Re: Infile statement issue running via UNIX, running fine on EGP in SAS Enterprise Guide

Infile statement issue running via UNIX, running fine on EGP

SAS_Help_4me — Fri, 10 Jan 2020 11:52:25 GMT

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.

Re: Infile statement issue running via UNIX, running fine on EGP

Ksharp — Fri, 10 Jan 2020 12:08:20 GMT

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;

Re: Infile statement issue running via UNIX, running fine on EGP

Kurt_Bremser — Fri, 10 Jan 2020 12:26:35 GMT

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.

Re: Infile statement issue running via UNIX, running fine on EGP

SAS_Help_4me — Fri, 10 Jan 2020 12:53:38 GMT

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 😞

Re: Infile statement issue running via UNIX, running fine on EGP

ChrisHemedinger — Fri, 10 Jan 2020 13:49:11 GMT

Other differences might be:

EG sets OPTIONS VALIDVARNAME=ANY, which might affect import steps that read inputs with nonstandard column names.
EG sets OPTIONS NOFMTERR, which allows more forgiving access to data when a user-defined format can't be found.

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.

Re: Infile statement issue running via UNIX, running fine on EGP

TomKari — Fri, 10 Jan 2020 14:40:59 GMT

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;

Re: Infile statement issue running via UNIX, running fine on EGP

Ksharp — Sat, 11 Jan 2020 11:11:26 GMT

Make sure this SAS code is created under UNIX ,not Windows .

Re: Infile statement issue running via UNIX, running fine on EGP

SAS_Help_4me — Thu, 16 Jan 2020 07:32:27 GMT

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!