| Security | This log contains information regarding the attempted access to unauthorized data. The information maintained includes failed login events and attempts to access unauthorized objects in the database. |
| Administration | This log tracks changes made to system objects such as users, groups, volumes, etc., and system events such as releasing an object. |
| Journal | This is a session log which tracks objects accessed from the database and the activities performed on those objects, as well as a trace through software modules. Each time you invoke or exit a module, the Log Manager posts an entry. Anytime access to an object occurs, an entry which includes the action (i.e., read, modify, create, delete, etc.) gets logged in the database. |
| System | This log contains entries which are about the operation of the platform such as startup and shutdown events of Teamcenter. |
| Application | This log tracks actions performed on objects at a session level, such as creation of folders, etc. |
Teamcenter creates a set of logs to monitor the use of the system. The logs can be broken up into two categories:
These logs are created with names of the form <application>.<jnl, trc, log> in the user's current working directory. The system logs are located in the directory $TC_LOG directory and are called administration.log, installation.log, security.log, and system.log.
The application log files contain high volume, application specific information. The log files contain information about significant events that take place in Teamcenter. These events include logging on to the system, creation of objects, deletion of objects, freezing of objects, etc.
The journal and traceback files contain information regarding specific subroutine calls made in Teamcenter.
The system logs record low volume, system events. For example, the security log includes information regarding attempted protection violation by users. The administration log contains information such as creation of a new user, new group, or volume. The system log can contain information such as the release of an item or dataset.
Preference files can control logging. You can enable application logs by placing an entry in either the user or site preference file. The entries are:
TC_Application_Logging={ON | OFF}
TC_Journalling={ON | OFF}
Tracebacks cannot be disabled.
You can control system logs by placing an entry in the site preference file. The entries are:
TC_Administration_Logging={ON | OFF}
TC_Security_Logging={ON | OFF}
TC_System_Logging={ON | OFF}
TC_Installation_Logging={ON | OFF}
The default is ON if no entry is found in the preference files.
The logging system initializes itself when the first event is posted to a log. There are only a few routines for posting entries in the various logs.
The event numbers reside in log.h in the directory $TC_INCLUDE. You can add your own user event numbers. Your new user event numbers must start with event number 9001. To add events, you define a new event number in log.h and create an appropriate message in log_text.uil in the $TC_SYS_UID_DIR directory.
The character string parm that you supply in the post_event calls is inserted into the log file to give more detailed information.
LM_post_info(LM_application_log(),LM_CREATE, folder_name); or LM_post_event(LM_security_log(), LM_ACCESS_VIOLATION, folder_tag, folder_name);
The format of the entries in the log files are: event_num user_name (os_name, hostname, application, date/time) - operation [tag] [parm].
| typedef enum LM_exception_class_e LM_exception_class_t |
| typedef enum LM_severity_e LM_severity_t |
| enum LM_exception_class_e |
| enum LM_severity_e |
| TC_API int LM_administration_log | ( | void | ) |
| TC_API int LM_application_log | ( | void | ) |
| TC_API int LM_disable_logging | ( | int | log_file | ) |
| log_file | (I) |
| TC_API int LM_enable_logging | ( | int | log_file | ) |
Routine to start and stop logging dynamically
| log_file | (I) |
| TC_API int LM_enabled | ( | int | log_file | ) |
| log_file | (I) |
| TC_API int LM_exit_module | ( | void | ) |
| TC_API int LM_init_module | ( | void | ) |
You invoke the initialize function to prepare the log manager for subsequent use. You can nest LM_init_module. That is, it may be called many times before any call to LM_exit_module.
LM_init_module no longer needs to be called. It is called automatically when an event is posted.
#include <tc/lm.h> procname() { int status; ... status = LM_init_module(); if (status != ITK_ok) { ...perform error handling } log manager facility functions status = LM_exit_module(); if(status != ITK_ok) { ...perform error handling via EMH } }
| TC_API int LM_install_log | ( | void | ) |
| TC_API int LM_journal | ( | void | ) |
| TC_API int LM_post_event | ( | int | log_file, | |
| int | event, | |||
| tag_t | tag, | |||
| const char * | parm | |||
| ) |
| TC_API int LM_post_info | ( | int | log_file, | |
| int | event, | |||
| const char * | parm | |||
| ) |
| log_file | (I) |
| event | (I) |
| parm | (I) |
| TC_API int LM_post_journal_exception | ( | tag_t | objectId, | |
| LM_exception_class_t | exceptionType, | |||
| LM_severity_t | exceptionSeverity, | |||
| const char * | userMessage | |||
| ) |
| objectId | (I) |
| exceptionType | (I) |
| exceptionSeverity | (I) |
| userMessage | (I) |
| TC_API int LM_security_log | ( | void | ) |
| TC_API int LM_system_log | ( | void | ) |