SAS GRID - View log file (from proc printto) while batch program is running

[jwilson]

Hi everyone,

Update:  I didn't think about this earlier, but the destination of the PROC PRINTTO is a CIFS mount, so I tried changing the path of the proc printto to a different location that was not a CIFS mount and was able to view the log while the program was running.  I am guessing there is some interaction between how PROC PRINTTO works and the how the mount is configured, though I'm not sure why or how.  I will continue investigating.  Maybe it has something to do with oplock?  I will keep digging.

[jwilson]

Next update:

OK, so the issue is definitely related to some sort of interaction between the CIFS mount and the log file being locked.  I'm working with support, and the next step was to add a line in my sasv9.cfg file to disable file locking on the directory I was sending my log to, and that did open up the file for viewing.  Of course, this is not a permanent solution since disabling file locking is not a good idea, but it did help diagnose the issue.

So I guess the question now becomes "is it possible to disable file locking only in the context of proc printto" OR "what the heck is going on with CIFS that it's essentially locking the file from both read and write and how do I fix that?"

I'm still working with support but just wanted to provide updates as they come.

[Tom]

Is this the CIFS you are talking about?

https://www.techtarget.com/searchstorage/definition/Common-Internet-File-System-CIFS#:~:text=CIFS%20....

CIFS is now considered obsolete, because most modern data storage systems use the more robust Server Message Block (SMB) 2.0 and 3.0 file-sharing protocols, which were major upgrades to CIFS.

[jwilson]

I don't think so. I am not really sophisticated to understand the subtleties of this, but I think that these days people use CIFS and SMB interchangeably. Our "CIFS" file system uses SMB 2.0.

[Tom]

I wonder whether they implemented that strange condition of preventing the reading of the log while it is being written as an artifact of the fact the way your SAS jobs are being run, with all of the logs are being directed to the same place.  Instead of being directed back to the filesystem used by the owner of the program being run, which would presumably already have the proper access roles in place so there is no need worry about the wrong people reading the file while it is being written.