Title: | Messaging Solutions MAKREL::MSG_SOLUTIONS |
Notice: | See 10.last for Enterprise Messaging Group Kit Information |
Moderator: | GOBUCS::COOLEY |
Created: | Thu Aug 06 1992 |
Last Modified: | Sat Apr 26 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 688 |
Total number of notes: | 2975 |
Hello, How can we control what is logged in MCM$TRACE.LOG file for MCM 1.0-001 ? We are trying also to push customer to upgrade to 1.1 but he doesn't want to go through this quite complicated upgrade for them. In the manual of MCM 1.1, I found a description how to define which level of message is logged by MCM: define a global symbol mcm$cvt_trace:==n in LOGIN.COM Does it work for v1.0 ? Does it exist other usefull symbols ? The problem behind this question is the MCM disk fragmentation caused by a big MCM$TRACE.LOG file that reach more than 600 extents dayly (for +/- 3500 blocks size). This log file badly impact the system performance. I must say that the disk used is a RZ26 (1 GB disk) defined with a cluster size of 3. The SYSGEN parameter RMS_EXTEND_SIZE is 0. The disk is dayly defragmented (with all applications stopped). Is there a way to pre-allocate space for MCM$TRACE.LOG to avoid so many extents creation (using a FDL file for instance) ? The final goal is to find a compromise between what needs to be logged and acceptable performance (the MCM disk is also used by Message Router and MailWorks server). The average ammount of dayly messages is about 20.000 (inbound + outbound) per cluster node (2 nodes cluster) including about 10.000 going through Message Router (and MCM). Thanks for advise Eric Collart MCS Brussels
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
684.1 | ACISS2::LENNIG | Dave (N8JCX), MIG, @CYO | Thu Feb 20 1997 12:33 | 18 | |
Note 317 has info on the various un-documented V1.1 features. MCM V1.0 is too far back for me to remember the particulars as to what was or wasn't available (most of the symbols WEREN'T in V1.0). With V1.1 you can also do stuff like define logicals in the login.com to redirect various bits around (for example to distribute I/O across spindles). Running MCM on the same disk as MR is a killer, since fetching/posting messages are in effect file copies (ie lots of seeks if MR$NBS and MCM$MSG areas are on same spindle). The V1.1 IVP procedure uses LOT's of 'tricks' (eg defining a logical to redirect MCM$TRACE.LOG to the terminal, using search lists, etc). Simply examining MCM$FE.COM/MCM$BE.COM/MCM$CVT.COM/MCM$START.COM will reveal a lot about how things work and the hooks that exist. Make sure when they upgrade that they are using the V1.1-002 kit (July 95) as it includes a number of important bug-fixes. Dave | |||||
684.2 | Thanks for info... | BACHUS::COLLART | Li p'ti fouineu - Dtn 856-8796 | Fri Feb 21 1997 02:46 | 9 |
Hello Dave, Thanks for the info, I will check note 317 (I missed it) Eric | |||||
684.3 | ACISS2::LENNIG | Dave (N8JCX), MIG, @CYO | Fri Feb 21 1997 06:52 | 3 | |
BTW, MCM$START.COM is where MCM$TRACE.LOG creation/roll-over occurs. Dave |