Is it possible to route the log of an Enterprise Guide SAS session, running on the server, to a file on the server?
The reason is that we would like to analyze what the user is doing for query performance optimization.
Thanks for your reply.
This would work, but a user has to program that himself.
I would like a generic way to route the log, without the user having to do anything, without him even knowing it.
I tried the altlog option on SAS server session invocation but that only gives startup and shutdown messages of the server session, not what the user executed.
Or do you think that putting the proc printto code in the server autoexec file would do the trick? I expect that the user then doesn't get his sas log in EG anymore.
to allow output and log to appear normally for user, you would have to trap -altlog.
It sounds like you have trapped the wrong -altlog.
If these jobs are started and run by an object spawner, then it is the start-up parameters for "spawned jobs" where you could insert some -altlog options.
to my sasv8.cfg.
After starting the session, running a Listing report on sashelp.class and closing the project, /tmp/sassession.log says:
1 The SAS System 22:10 Saturday, October 28, 2006
NOTE: Copyright (c) 1999-2001 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) Proprietary Software Release 8.2 (TS2M0)
Licensed to E.O.M. DATA B.V., Site 0088045005.
NOTE: This session is executing on the Linux 2.6.17-2-686 platform.
NOTE: This installation is running Base SAS hot fix bundle 82BX09.
This message is contained in the SAS news file, and is presented upon
initialization. Edit the files "news" in the "misc/base" directory to
display site-specific news and information in the program log.
The command line option "-nonews" will prevent this display.
NOTE: SAS initialization used:
real time 0.05 seconds
cpu time 0.00 seconds
NOTE: Bridge protocol engine is closing connection with client that has concluded processing.
NOTE: The SAS System used:
real time 59.70 seconds
cpu time 0.12 seconds
You have demonstrated the point I was trying to make.
The infromation that you have trapped is not the session log you seek, but the session spawned by the server ~~ which calls yet-another session where your SAS code is run. I hope one day to discover just where that session's parameters are obtained. I do know that the similar spawning/calling sequence for running SAS DI Studio jobs, results in the autoexec and verbose options being ignored (other options may be ignored but I don't know). "Ignoring" like this guarantees problems, imho.
Somewhere the caller of the session that actually processes your code has parameters like -sysin and perhaps could be extended to accept -altlog. Continue to search and ask.
We also have the same problem where the log file is hardcoded in PROC PRINTTO statement. If there is a way to automate it on the server side to create a seperate log file per day per session... that would be highly appreciated.