MQSeries.net :: View topic

tczielke · Posted: Sat Mar 17, 2018 5:27 am Post subject:

rekarm01 added some helpful information from the manual on how this works and how it changed at 9.0.4. I wanted to also just highlight the following for Linux/Unix.

1) On Linux (probably most other Unix systems, too) a file is identified by its inode, not its hard link. A name like /var/mqm/qmgrs/QM1/errors/AMQERR01.LOG is really a hard link to that inode, and is not what uniquely identifies the file. You can have multiple hard links to the same inode. So it is possible to have two hard links AMQERR01.LOG and MONKEY both pointing to the same inode 1234 and 1234 is what really truly identifies the file, not AMQERR01.LOG. If you do writes to both the hard links of AMQERR01.LOG and MONKEY, they both get written to the inode 1234.

2) A file will not be removed by Linux (and probably other Unix systems, too) until all hard links are removed to the inode AND no processes have that inode open. This is one reason why the rm (remove) command is called rm and not del. You are not deleting a file when you run the rm command. You are removing a hard link to the inode. Let's say there is only one hard link (e.g. AMQERR01.LOG) to the inode 1234. You can do a "rm AMQERR01.LOG" and remove the hard link, but as long as a process has inode 1234 open, that inode will never be deleted by the operating system.

You need to take the above into consideration when desigining any application to read the AMQ error logs. With the 9.0.4 approach, it sounds like you could get yourself into a situation where a long running process that is reading the AMQ error logs could prevent the underlying file inode for AMQERR03.LOG from being deleted by the operating system, if you are not careful with your design.
_________________
Working with MQ since 2010.