Tips for Monitoring SAS Logs in Real-Time on Windows

For SAS^© developers accustomed to the Unix environment, the tail -f command is an essential reflex: it allows you to watch the log file populate as a program executes. However, when switching to a Windows environment (especially for batch mode executions), this task often becomes frustrating. Windows frequently locks files that are being written to, preventing them from being read, or the buffering system leaves the file empty (0 KB) for long minutes.

Here is a compilation of solutions and tips from expert exchanges to work around these limitations on Windows.

The Locking Problem: Which Editor to Choose?

One of the major problems on Windows is the "Access Denied" message or the inability to open a log file while SAS^© is writing to it.

Avoid: WordPad. Although WordPad handles line breaks better on large files, it tends to handle concurrent access poorly and may refuse to open a file that is in use by SAS^©.
Preferred: Notepad. Contrary to popular belief, the standard Windows Notepad can often open log files in read-only mode while SAS^© is running, where WordPad fails.
The web browser trick: A little-known but very effective solution is to open your .log file directly with a browser (Internet Explorer, Chrome, Edge, etc.). The browser does not lock the file and displays the text correctly (especially if the extension is .log, the formatting remains readable).

Note :
The "Dashboard" Solution: PROC PRINTTO and HTML
To go beyond simple text reading, you can redirect your logs to an HTML format. This allows you to create real monitoring dashboards (with colored statuses: green for finished, yellow for in progress, etc.).

The idea is to use the PROC PRINTTO procedure to route the log to an HTML file. Here is an example of a macro proposed by the community:

1	%MACRO PRINTTO(_logPath=, _jobID=, _jobName=);
2	%LOCAL dt;
3	%LET dt = %sysFunC(dateTime(), DATETIME16.);
4
5	/* Initialisation du fichier HTML */
6	FILENAME L_PATH "&_logPath";
7	DATA _null_;
8	file L_PATH;
9	put "<PRE>"; /* Balise pour conserver le formatage */
10	RUN;
11	FILENAME L_PATH CLEAR;
12
13	/* Redirection de la log */
14	PROC PRINTTO LOG = "&_logPath";
15	RUN;
16
17	%PUT NOTE: Job &_jobID - &_jobName a demarre a &dt;
18	%MEND;

By opening this HTML file in a browser and using automatic refresh, you can comfortably track the progress of your jobs.

The Empty File Problem (Buffering)

Even if you manage to open the file, its size often remains stuck at 0 KB or does not update for long periods, even if the program is running.

This is a buffering problem. SAS^© (and the operating system) stores information in memory before physically writing it to the disk in blocks (pages) to optimize performance.

How to Force Writing to Disk?

There is a poorly documented but very useful startup (invocation) option for this specific case: -unbuflog.

Usage: This option should be added to your SAS^© launch command line or your configuration file (sasv9.cfg).
Effect: It tells SAS^© not to buffer the log and to write the lines as they are generated.
Limitations: Although very useful, this option does not always guarantee an instant, second-by-second update (it also depends on the disk load and the OS), but it significantly reduces the delay in the appearance of logs.

You can also combine this with the -logparm option: -logparm "write=immediate rollover=session"

4. Third-party Tools: Bringing Unix to Windows

If you miss tail -f too much, the radical solution is to install utilities that bring Unix commands to Windows. Tools like GnuWin32, UnxUtils, or Cygwin allow you to use tail on Windows to monitor your log files exactly as you would on a Linux server.

Do not use WordPad.
Use Notepad or your web browser to view the file without locking it.

Avertissement important

Les codes et exemples fournis sur WeAreCAS.eu sont à but pédagogique. Il est impératif de ne pas les copier-coller aveuglément sur vos environnements de production. La meilleure approche consiste à comprendre la logique avant de l'appliquer. Nous vous recommandons vivement de tester ces scripts dans un environnement de test (Sandbox/Dev). WeAreCAS décline toute responsabilité quant aux éventuels impacts ou pertes de données sur vos systèmes.

Retour à la liste des articles