BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
econ
Quartz | Level 8


I'm trying to get the log file from submitting a program in EG using the X command.

From the linux command line this runs as expected and produces the log.

sas "/pm/code/HazardIII v1.0/cmg/devdeclone/simulation/run2003.sas" -log "/pm/code/HazardIII v1.0/cmg/devdeclone/log/run2003.log" &

When I run the exact statement in EG using the X command there is no log produced and the program doesn't run as expected. Watching the temp folder after submitting the code with X I think I see where the code is getting tripped up at, but can't get the log so I can't tell what the error is. 

1 ACCEPTED SOLUTION

Accepted Solutions
Peter_C
Rhodochrosite | Level 12

You could add the NOPRINT option to the PROC SQL statement to stop that particular issue but another procedure might try to write to the Output "window".

The big fix - route Output a.k.a Listing, to another file in a folder where it will have write permission by adding to the launch of SAS

-print "suitable path/print.lst"

View solution in original post

17 REPLIES 17
jakarman
Barite | Level 11

Several things.

a/ The code with X will often not give you any messages frrom the OS level. The use of the filename with pipe will give you more control on that.

b/ Eguide is using a workspace server defined by scripts in the OS tree at:   -/Levx-/SASapp/-   There is a workspace entry and possible more.

    These scritpts are being tuned for a dedicated use. The current directory is set at that location not you home-directory as usual by default.

c/ The Eguide process is a forked process started by the objectspawner. That is most settings you would expect by using ssh are not done.

d/ The Eguide process although started by does not need to be run by the same key you would use with ssh.  

Well knowing this you can more easy correct all the resulted issues of that.  

You cannot expect with all those differences the command line of Linux behaving the same as in Eguide.

When you sas script in ssh is run by some setting in your .profile than that is one issue.

The print-file (.lst)  is not defined when it will be tried to open, the wrong location it will halt by a security failure as the location is not ~ (your homedir)

When your Eguide proces is run using a shared account, .... good luck.    

---->-- ja karman --<-----
econ
Quartz | Level 8

thanks for this. found out i needed to use -altlog instead of -log.

now that i have the log i'm getting the error you reference. trying to debug it now.

 

ERROR: Insufficient authorization to access /opt/sas/eg/Lev1/SASApp/run2003.lst.

this code works to get the log file using X command.

x sas "&basedir.simulation/run2003.sas" -altlog "&basedir.log/log2003.log" &;

Peter_C
Rhodochrosite | Level 12

define also

-altprint "&basedir.log/log2003.lst"

econ
Quartz | Level 8

Getting stuck right here.

 

MPRINT(CLONES): proc sql;

MPRINT(CLONES): select count(*) as prem_plan_total into :prem_plan_total from prem_plan;

ERROR: Insufficient authorization to access /opt/sas/eg/Lev1/SASApp/run2003.lst.

NOTE: The SAS System stopped processing this step because of errors.

NOTE: SAS set option OBS=0 and will continue to check statements. This might cause NOTE: No observations in data set.

NOTE: The PROCEDURE SQL printed page 1.

NOTE: PROCEDURE SQL used (Total process time):

real time 0.01 seconds

cpu time 0.01 seconds

econ
Quartz | Level 8

i changed the proc sql; proc sql noprint; and it got through the step.

it doesn't seem like the -altprint is being applied.

Peter_C
Rhodochrosite | Level 12

You could add the NOPRINT option to the PROC SQL statement to stop that particular issue but another procedure might try to write to the Output "window".

The big fix - route Output a.k.a Listing, to another file in a folder where it will have write permission by adding to the launch of SAS

-print "suitable path/print.lst"

econ
Quartz | Level 8

i think that did it. thanks!

jakarman
Barite | Level 11

You were lucky with the altlog option, it did started sas and logged something.  It could be one of the other options.
The root cause is: 50345 - Changing the current working directory for the SAS® Workspace Server

knowing this it is also easy to solve that. There are many ways

- ask your platform admin to correct the default home according that note

- do a cd ~ or cd $HOME (what ever works) so your x-command will be " cd $HOME ; sas ......"

- define a fully qualified name (path/name) to that *.lst file as you did for the source-file and the log-file   
  SAS(R) 9.4 Companion for UNIX Environments, Third Edition (print system option)

The alt options (altlog altprint) are duplicating to log print and not preventing the security issues on log and print usage.

For archiving the pipe command SAS(R) 9.4 Companion for UNIX Environments, Third Edition

---->-- ja karman --<-----
econ
Quartz | Level 8

thanks. i'll have my guy take a look.

Tom
Super User Tom
Super User

I find it much easier to debug if I use a pipe inside a data step instead of the simple X command.

data _null_;

  infile "my os command" pipe end=eof ;

  input ;

put _infile_;

run;

That way any error messages that the operating system tried to give me about the command will be written to the log of the calling SAS program.

econ
Quartz | Level 8

this is the complete syntax i used.

x sas "&basedir.simulation/run2003.sas" -altlog "&basedir.log/log2003.log" -print "&basedir.log/print2003.lst" &;

is it just me or is the information out there really lacking on using X command?

i just got it working last friday and am totally blown away by what it can do. i'm probably getting greedy, but i want more.

anything you guys can point me to on a sweet spot for how many jobs can be running at one time and how to manage them in a no access to SAS/CONNECT product environment?

Kurt_Bremser
Super User

The number of jobs running concurrently is usually limited by the operating system, globally by the capabilities of OS & HW and individually by limits set for the user by the systems admin.

I would advise, though, to run jobs in succession. Multiple concurrent SAS jobs (using the same configs) may overstress the work locations, leading to "file full" conditions and poor performance because of I/O bottlenecks.

One hint: try

x "cd '&basedir'; sas 'simulation/run2003.sas' -altlog 'log/log2003.log' -print 'log/print2003.lst'" &";

or, in a data_null_ step, put the whole command in a variable and use call system();

jakarman
Barite | Level 11

econ as you are aware what you can do with it, you have the reason of the why:

- schedulers are that nice (LSF  grid processing).

- using OS commands can have that much of returns.

How many jobs you can run? That is a question of load-balancing (LSF the L is for Load).

You can submit  light or heavy jobs by this that is why planning of those jobs is essential.

This is at the same time sometimes the reason the X-CMD is blocked by you IT-staff. They have the feeling no being in control any more.  

What you can do? There are a lot ways to use X-cmd with SAS with better control.  Macro-based, datastep based, using pipes (See Tom's coding)  and one is the SYSTASK

SAS(R) 9.3 Companion for UNIX Environments . With that you can monitor the running tasks.   (taskname). Same approach as using SAS/connect.

Take care to use Eguide not setting in a parallel execution mode as that lose some session settings.   

The SAS/Connect MP-connect is local batch processing in the same way as you did now. It is just starting a local script not using the TCPIP connection

For tuning on the OS-level you could think of setting op using Cgroups.  cgroups - Wikipedia, the free encyclopedia By that you will be able to prevent a global system overload (thrashing) by segregating that in groups. Only some newer Linux versions are having that.

---->-- ja karman --<-----
econ
Quartz | Level 8

is there a way to pin a job to a specific CPU?

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 17 replies
  • 5066 views
  • 8 likes
  • 6 in conversation