Program is behaves different when executed with cron

[iscgonzalez]

Hello guys,

I'm having some issues with the following code

filename dsk_stat pipe "sar -d";

data dsk_status;
	infile dsk_stat length=reclen truncover;
	input buffer $varying200. reclen
		hour $1-11;
	dev = scan(buffer,3,' ');
	tps = scan(buffer,4,' ');
	avgrq = scan(buffer,7,' ');
	avgqu = scan(buffer,8,' ');
	await = scan(buffer,9,' ');
	svctm = scan(buffer,10,' ');
	util = scan(buffer,11,' ');
	if dev = 'dev253-10';
run;

data dsk_status;
	set dsk_status;
	format hrs timeampm8.;
	hrs = input(hour,time11.);
	read = input(scan(buffer,5,' '),best10.);
	write = input(scan(buffer,6,' '),best10.);
	drop buffer;
run;

When I run it from EG or when I submit the program by the linux console (sas myprogram.sas -log myprogram.log) it runs perfectly, but for some reason when I schedule the same command to execute on cron, I get 0 observations on the log.

Isn't it supposed to be the same result when I invoke it from the linux console than when cron does? Anyone has experienced something similar?

PS. This is part of a report that I'm building to monitor the server status. I'm using sas 9.4

[ballardw]

I would expect cron to invoke batch mode and many installations have different setups for batch vs interactive mode.

As a minimum you should show the command line invoked by cron and the settings used when opening for interactive mode (program object settings).

Likely they are 1) pointing to different configuration files and 2) possibly the cron starts the SAS program from a server perspective and not the same as your interactive sessions.

You might also post the log from the program, especially the start up bit until the likely first error or Zero record data set.

Post the information in separate code boxes opened with the forums {I} menu icon, especially for the log to preserve formatting of any error messages.

[iscgonzalez]

Hello ballardw,

crontab has the following command line

0 9,12,16 * * 1-5 /sas/sas94/SASHome/SASFoundation/9.4/sas /SASROOT/Administracion/Reporteo/monitor_servidor/ServerStatus.sas -log /SASROOT/Administracion/Reporteo/monitor_servidor/ServerStatus.log >/dev/null 2>&1

In the log nothing like an error is displayed:

3          
4          filename dsk_stat pipe "sar -d";
5          
6          data dsk_status;
7          	infile dsk_stat length=reclen truncover;
8          	input buffer $varying200. reclen
9          		hour $1-11;
10         	dev = scan(buffer,3,' ');
11         	tps = scan(buffer,4,' ');
12         	avgrq = scan(buffer,7,' ');
13         	avgqu = scan(buffer,8,' ');
14         	await = scan(buffer,9,' ');
15         	svctm = scan(buffer,10,' ');
16         	util = scan(buffer,11,' ');
17         	if dev = 'dev253-10';
18         run;

NOTE: The infile DSK_STAT is:
      Pipe command="sar -d"

NOTE: 1227 records were read from the infile DSK_STAT.
      The minimum record length was 0.
      The maximum record length was 114.
NOTE: The data set WORK.DSK_STATUS has 0 observations and 9 variables.
NOTE: DATA statement used (Total process time):
      real time           0.12 seconds
      cpu time            0.02 seconds
      

19         
20         data dsk_status;
21         	set dsk_status;
22         	format hrs timeampm8.;
23         	hrs = input(hour,time11.);
24         	read = input(scan(buffer,5,' '),best10.);
25         	write = input(scan(buffer,6,' '),best10.);
26         	drop buffer;
27         run;

NOTE: There were 0 observations read from the data set WORK.DSK_STATUS.
NOTE: The data set WORK.DSK_STATUS has 0 observations and 11 variables.
NOTE: DATA statement used (Total process time):
      real time           0.04 seconds
      cpu time            0.03 seconds

while if I execute directly the same command that is in crontab on the linux command line:

/sas/sas94/SASHome/SASFoundation/9.4/sas /SASROOT/Administracion/Reporteo/monitor_servidor/ServerStatus.sas -log /SASROOT/Administracion/Reporteo/monitor_servidor/ServerStatus.log

I get the following log:

3          
4          filename dsk_stat pipe "sar -d";
5          
6          data dsk_status;
7          	infile dsk_stat length=reclen truncover;
8          	input buffer $varying200. reclen
9          		hora $1-11;
10         	dev = scan(buffer,3,' ');
11         	tps = scan(buffer,4,' ');
12         	avgrq = scan(buffer,7,' ');
13         	avgqu = scan(buffer,8,' ');
14         	await = scan(buffer,9,' ');
15         	svctm = scan(buffer,10,' ');
16         	util = scan(buffer,11,' ');
17         	if dev = 'dev253-10';
18         run;

NOTE: The infile DSK_STAT is:
      Pipe command="sar -d"

NOTE: 1227 records were read from the infile DSK_STAT.
      The minimum record length was 0.
      The maximum record length was 114.
NOTE: The data set WORK.DSK_STATUS has 71 observations and 9 variables.
NOTE: DATA statement used (Total process time):
      real time           0.03 seconds
      cpu time            0.03 seconds
      

19         
20         data dsk_status;
21         	set dsk_status;
22         	format hrs timeampm8.;
23         	hrs = input(hora,time11.);
24         	read = input(scan(buffer,5,' '),best10.);
25         	write = input(scan(buffer,6,' '),best10.);
26         	drop buffer;
27         run;

NOTE: There were 71 observations read from the data set WORK.DSK_STATUS.
NOTE: The data set WORK.DSK_STATUS has 71 observations and 11 variables.
NOTE: DATA statement used (Total process time):
      real time           0.02 seconds
      cpu time            0.03 seconds

I also checked with a pipe and the command whoami with which user crontab was executing and the user was sas. Also checked with proc options in both ways (crontab and linux console) and it gave me the same options set.

[ballardw]

Your code here:

6          data dsk_status;
7          	infile dsk_stat length=reclen truncover;
8          	input buffer $varying200. reclen
9          		hour $1-11;
10         	dev = scan(buffer,3,' ');
11         	tps = scan(buffer,4,' ');
12         	avgrq = scan(buffer,7,' ');
13         	avgqu = scan(buffer,8,' ');
14         	await = scan(buffer,9,' ');
15         	svctm = scan(buffer,10,' ');
16         	util = scan(buffer,11,' ');
17         	if dev = 'dev253-10';
18         run;

NOTE: The infile DSK_STAT is:
      Pipe command="sar -d"

NOTE: 1227 records were read from the infile DSK_STAT.
      The minimum record length was 0.
      The maximum record length was 114.
NOTE: The data set WORK.DSK_STATUS has 0 observations and 9 variables.
NOTE: DATA statement used (Total process time):
      real time           0.12 seconds
      cpu time            0.02 seconds

Shows that the input set was apparently read correctly. Since the only thing that would reduce the number of output observations in the data is the statement:

if dev = 'dev253-10';

It may be that the value you are looking for should be 'DEV253-10' dev has that value as part of a longer string.

IF you run the exact same code with the same environment in interactive mode the issue could be with how the sar command works in the batch mode. Modify your code to remove the "if" to see what values are there for dev and that might help.

I'm not a unix or related guru in any form but it may be that the sar command is being run in the /sas/sas94/SASHome/SASFoundation/9.4 folder since I don't see anything to change a default path. What would the result be if you move to that location and run the sar command?

[Kurt_Bremser · Accepted solution]

Drop the subsetting if and see which values you get when run from cron.

[ChrisHemedinger]

When I schedule a program with cron here at my work, it runs on a designated cron server -- not the same as the Linux pool where my interactive SAS sessions run.  The environment is compatible -- file-access and software-wise, but it's not the same box.  Could that be a factor?  

Try "crontab -l" and see if the command shows you where it's executing.  Then rlogin to that box (if different) and see if your program has the same result.

[iscgonzalez]

Thanks, for your suggestion, it lead to my solution, for some reason when I executed manually, the command output was sligthly different to the output that I had when the task run with cron.

Probably the lesson learned here is that when you work with pipes and cron, you should double check what you are getting as a result from a command execution, because it may not be the same results that you have when executing manually the command.