Hello,
I have a AIX/Unix script that runs a SAS program along with other debugging SAS commands as shown below:
#!/bin/ksh
ls -altr > /cml_jobs/cim/dev/users/k85671/scripts/content1.txt
.profile
sas /cml_jobs/cim/dev/users/k85671/scripts/cimport.sas -altlog /cml_jobs/cim/dev/users/k85671/scripts/cimportlog.txt
ls -altr > /cml_jobs/cim/dev/users/k85671/scripts/content2.txt
I call this script through this code which is a proc run through a JCL
NDMRUN2 PROCESS -
HOLD=NO /* YES, NO, OR CALL */ -
PNODE=HI.CHICAGO /* DESTINATION */ -
SNODE=VH2_NABISAS /* SOURCE */ -
RETAIN=NO
STEP1 COPY FROM (PNODE DSN=&INDSN DISP=SHR -
SYSOPTS=":DATATYPE=BINARY:") -
TO (SNODE DSN=&OUTDSN DISP=RPL -
SYSOPTS=":DATATYPE=BINARY:")
STEP2 RUN TASK SNODE (PGM=UNIX) -
SYSOPTS="/cml_jobs/cim/dev/users/k85671/scripts/ls.ksh"
When I run the script on PuTTY, it runs like a breeze. However, when I run the JCL, all the commands run except the SAS pgm. The NDM logs are clean. But the file "cimportlog.txt" is not created while the files above and below are created (content1.txt, content2.txt)
Unsure of the the issue is.....
Any help is appreciated.
Are the users that run your script the same?
The JCL itself should create a log, look there.
One reason that a SAS batch run does not create a log file is a missing program file. If the JCL does not catch stderr, the relevant message might never appear where you can find it.
This really smells like different environments between JCL and your commandline. Maybe the JCL ID can't read in your home directory.
Hmm. I see something:
#!/bin/ksh ls -altr > /cml_jobs/cim/dev/users/k85671/scripts/content1.txt .profile sas /cml_jobs/cim/dev/users/k85671/scripts/cimport.sas -altlog /cml_jobs/cim/dev/users/k85671/scripts/cimportlog.txt ls -altr > /cml_jobs/cim/dev/users/k85671/scripts/content2.txt
This .profile may be bogus.
Why?
If it sets environment variables, it does so in a shell forked off the one that runs the scripts. When it terminates, all changes are lost.
Use
. /path_to_your_home_directory/.profile
instead if you want to make sure that another user gets your environment. If "sas" is not found, and stderr is not correctly captured, your shell script will exit with the exit code from the last command, which won't fail.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.