The dmlockmgr(8) process must be executing at all times for any DMF process to safely access and update a DMF database. The dmlockmgr and its clients (DMF processes such as dmatmsp, dmdaemon(8), dmvoladm(8), dmcatadm(8) and others) communicate through various methods. These methods include files, semaphores, and message queues. There are times when abnormal process terminations will result in non-orderly exit processing which will leave files and/or interprocess communication (IPC) resources allocated. As a DMF administrator, periodically you will want to look for these resources to remove them.
|Note: In this chapter, SPOOL_DIR refers to the value of the SPOOL_DIR parameter in the DMF configuration file.|
The dmlockmgr files used by the database utilities are found in several different places. There are 3 types of files:
dmlockmgr communication and log files
Individual transaction log files
The dmlockmgr communication and log files are all found in a directory formed by SPOOL_DIR/RDM_LM. This directory contains the token files used to form the keys that are used to create and access the IPC resources necessary for the dmlockmgr to communicate with its clients, its standard output file, and the transaction file.
The token files in SPOOL_DIR/RDM_LM have the form shown in Table 5-1:
Used by the dmlockmgr and its clients to access dmlockmgr's semaphore and input message queue
Used by the MSP msp_name and dmlockmgr to access the MSP's input message queue
Used by the DMF daemon and dmlockmgr to access the daemon's input message queue
Used by the process whose process ID is PID to access the process's input message queue
The dmlockmgr, dmatmsp, and dmdaemon token files are limited in number, and they change infrequently. If a dmlockmgr, dmatmsp, or dmdaemon terminates without removing the file, an existing token file will be used on restart. If a dmatmsp or dmdaemon fails to remove the file and MSP name is changed, the file will remain until it is manually removed.
The files of the PID versions listed in Table 5-1 are removed from the lockmgr directory automatically when the command terminates or when the DMF daemon initializes. Do not create files of this name format in this directory because the daemon is likely to remove them.
The IPC resources used by DMF are always released during normal process exit cleanup. If one of the dmlockmgr client processes dies without removing its message queue, dmlockmgr will remove that queue when it detects the death of the client. It will not remove the token file.
|Note: Normally, the dmlockmgr process is terminated as part of normal shutdown procedures. However, if you wish to stop it manually, you must kill the process by using kill(1). Killing the dmlockmgr process does not remove the dmlockmgr IPC resources or token file. If the dmlockmgr is restarted automatically by a DMF process, it will reuse the token file and IPC resources it left behind.|
If the dmlockmgr process aborts, all DMF processes must be stopped and restarted in order to relogin to a new dmlockmgr process. If the dmdaemon or dmatmsp processes abort during a period when the dmlockmgr has died, when they restart they will attempt to restart the dmlockmgr. The new dmlockmgr process will detect existing DMF processes that were communicating with the now-dead copy of dmlockmgr, and it will send a termination message to those DMF processes.
The dmlockmgr maintains a log file that is named as follows, where yyyy, mm, and dd are the year, month, and day:
The log file is closed and a new one opened at the first log request of a new day. These files are not typically large files, but a new file will be created each day and you should periodically remove older versions. You should maintain the dmlockmgr log files for as long as you maintain the database transaction journal files.
The individual transaction log files have the following form:
dmatmspmsp_name.log dmdaemonPID.log dmvoladmPID.log dmcatadmPID.log dmdbasePID.log dmdbrecoverPID.log dmselectPID.log
Most of the transaction log files will reside in the database directory (HOME_DIR/daemon_name for the dmdaemon, HOME_DIR/msp_name for the dmatmsp). In the case of the dmdaemon and dmatmsp, each new transaction will reuse the same file generated by the last transaction, and there is no need to remove these files.
In the case of the PID transaction log files, the commands that generate them will generally remove them during their normal exit processing code. If there is an abnormal termination, these files will not be removed, and they may be quite large.
|Caution: Do not delete any orphaned transaction log files until you are sure the database is not actively in use. If a process aborts during a committed but incomplete transaction, the next process that contacts the dmlockmgr will use the information in the transaction log file to recover the incomplete transaction.|
After you are sure the transaction log file will not be needed, it can be removed.
It is wise to periodically check for these files. Several DMF commands allow accessing of copies of database files in places other than the standard location, which may result in unnecessary transaction log files consuming disk space.
The transaction activity file, SPOOL_DIR/RDM_LM/vista.taf, is the transaction log file that contains information about active transactions in the system. It is used to facilitate automatic database transaction processing.
|Caution: Do not delete the SPOOL_DIR/RDM_LM/vista.taf file.|