New post
AllAccepted answers
Fabian Haupt · Sep 2, 2016

Just for clarification, this is known behaviour:

info coreutils 'chown invocation':

   The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits.  This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking).  When in doubt, check the underlying system behavior.
Fabian Haupt · Sep 1, 2016

Please note that this example uses the old (deprecated) dot-syntax for the loop. It also loops through your data twice. Nowadays you would write the same more like this:

#include %occInclude
ListDir
 set statement=##class(%SQL.Statement).%New()
 set status=statement.%PrepareClassQuery("%File","FileSet")
 if $$$ISERR(status) { do $system.OBJ.DisplayError(status) }
 set resultset=statement.%Execute("c:\temp","*","",1)
 while resultset.%Next() {
    write:resultset.%Get("Type")="D" !, resultset.%Get("Name")
 }
Fabian Haupt · Aug 28, 2016

Hi Alexander,

The problem was: with just removing the directory, the processes are still hanging around. So the 1972 port was still in use by the original cache instance. 

Restarting removed that process, that's why it solved the issue. Part of Dmitry's answer was useful in such as you can use lsof to determine which process holds a handle on a port. 

Please let me know if you have any further questions about this!

HTH,

Fab

Fabian Haupt · Aug 5, 2016

Hi Marc,

you can use PERFMON [1] to collect statistics about which globals are being accessed.  This will allow you to monitor a process and then distinguish between your globals being accessed and system globals. 

That being said, I don't quite see why would would need that distinction. Where do you draw the line? When you write a sql query and it gets compiled into a routine, would you consider that being your code, or Caché's code? 

There are a couple of global accesses that will happen when you run your code, such as loading a routine (classes get compiled into routines). However, as soon as that has happened once, the routine will be in the routine buffer, so no further disc access will happen. Overall, if your application handles any amount of data that goes beyond a couple of blocks, the 'system accesses' will be negligible. 

In your example you are seeing the first time the routine is being loaded, hence the 4 references. A more realistic example would be to access 100000 random global nodes in your random class. There will still be a more accesses but 3/100000 really doesn't matter by any metric you might employ. 

I hope this addresses your concerns. 

Best,Fab

[1]http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_perfmon#GCM_perfmon_using

Fabian Haupt · Jul 14, 2016

There is ^%GSIZE which will give you an overview of the usage per global. However, if you have a normal size database (>1TB) this is going to take a while. 

I have written statistical approaches in the past. I'll clean up one of them and post it on the community if there is enough interest. (that one actually has a graphical display of the results) 

Best,

Fabian