Life is much simpler if you avoid reading syslogs and leave the interpretation of what might be there to the experts.
I'm dead serious!
The only time you should EVER be concerned about what might be recorded in a syslog is if and when you see an actual error message displayed on the screen or if NX crashes without an error message (which is VERY rare, but not unheard of). In those circumstances, particularly if this is something which you can reproduce easily, you should contact GTAC and provide them with at least the syslogs and hopefully the parts files and a description of the workflow which lead to the problem.
What you often see in syslogs are entries which may be flagged in such a way as to appear to be an error (yet nothing was displayed on the screen or any other manifestation of a problem was experienced), are often of value only to the 'experts' and in the vast majority of the cases are meaningless, even to them. Often during the development process programmers leave code in their projects which amounts to low-level diagnostics which uses what is normally error-trapping mechanisms even if they never raise a real error to the user level. While these should really have been removed before final integration they are often overlooked and can almost always be ignored (which is one of the reasons why I said I was
dead serious about NOT making a habit of reading syslogs in the first place).
As for your so-called 'expert' ignoring you, I don't know who that might have been or what you asked him (or her) to do, but even if he was able to track down these 'phantom errors' I suspect that there would be very little that he could relay back to you which would in any way enlighten you as to what was happening or even if it was something which you had any control over in the first place. As I said, they are often just low-level 'noise' and were never intended to have any meaning to anyone other than the original programmer and even then they often only indicate that something happened in a certain way, often as expected. In fact, we have many functions which actually were written with the assumption that they will sometimes 'fail', but the detection of this 'failure' and what is returned as diagnostics, is often used as part of the logic when deciding on using an alternative approach to solve the original task.
John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Cypress, CA
To an Engineer, the glass is twice as big as it needs to be.
