BookmarkSubscribeRSS Feed
jwilson
Obsidian | Level 7

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
Obsidian | Level 7

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
Super User Tom
Super User

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
Obsidian | Level 7
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
Super User Tom
Super User

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.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 34 replies
  • 1425 views
  • 3 likes
  • 6 in conversation