This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
Yes - with a lot of work and the cleaner you keep it the better your system will appear to run...
R/
Will
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Jason Verly
Sent: Monday, October 01, 2012 11:00 AM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
In a perfect world, I would think that Maximo should keep the error log clean. However in the real world it's just not possible.
One thing that will clutter the error logs is the use of conditional expressions. We have found that if you us them, you will consistently see false errors in the logs such as the following:
java.sql.SQLException: ORA-00904: "WORKORDER"."LOCATION": invalid identifier
Obviously WORKORDER.LOCATION is NOT an invalid identifier. We had a PMR to IBM and they explained it to us like this: All conditional expressions will first execute against the dummy table (for some reason I can't recall right now but didn't quite agree with) before executing against the actual object. So this is just one example of something that appears in the error log that is not actually an error.
So it's unlikely that you could ever keep the error log completely clean. Moreover there is so much noise that monitoring is highly problematic. I don't even attempt to monitor the UI error logs anymore, only the MIF instance.
-----Original Message-----
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Jason Verly
Sent: Monday, October 01, 2012 12:00 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
Ha! That explains why I see on occasion an error message related to work order history flag or a purchase order status in the error log. tyvm!
--- In MAXIMO@yahoogroups.com, "Hanna, Christopher CTR" <christopher.a.hanna@...> wrote:
>
> In a perfect world, I would think that Maximo should keep the error log clean. However in the real world it's just not possible.
>
> One thing that will clutter the error logs is the use of conditional expressions. We have found that if you us them, you will consistently see false errors in the logs such as the following:
>
> java.sql.SQLException: ORA-00904: "WORKORDER"."LOCATION": invalid identifier
>
> Obviously WORKORDER.LOCATION is NOT an invalid identifier. We had a PMR to IBM and they explained it to us like this: All conditional expressions will first execute against the dummy table (for some reason I can't recall right now but didn't quite agree with) before executing against the actual object. So this is just one example of something that appears in the error log that is not actually an error.
>
> So it's unlikely that you could ever keep the error log completely clean. Moreover there is so much noise that monitoring is highly problematic. I don't even attempt to monitor the UI error logs anymore, only the MIF instance.
>
>
>
> -----Original Message-----
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Jason Verly
> Sent: Monday, October 01, 2012 12:00 PM
> To: MAXIMO@yahoogroups.com
> Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
>
>
>
> This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
>
> So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
>
It has to do with trying to keep from having queries that return the whole db (dummy proofing, or ignorant proofing if your "PC")
Imagine if you ran a query that essentially was like this ":sitied = 'EAGLENA'" - when Maximo processes this and sends it to the db you get "select * from workorder where 'EAGLENA' = 'EAGLENA'" and if all your records are in the one site... you get them all...
This was a huge problem in Workflow as people didn't understand it. In version 6.2 they implemented a preprocessor that checked to see if the statement could be resolved in memory - if it could it was never sent to the db. That took care of the bulk of the problem. The above syntax wouldn't be sent to the database and the record would move along quickly.
Syntaxes that have subselects, exists or not exists clauses, etc. now are sent to the db - but you can still end up with the same problem, the subselect returns "true" and the query becomes "select * from workorder where 'APPR' in (select value from synonymdomain where maxvalue = 'APPR')" if not written properly...
In 7.1'ish someone made a rash decision and started testing against the dummy table to see if the condition was true or false and in that way they "fixed" the return the db problem... but like many decisions it was short sighted - it broke the ability to have a complex SQL statement in the where clauses - ones that have both fields AND subselects, exists, not exists etc... you couldn't write "siteid = :siteid and wonum = :wonum and :status in (select value from synonymdomain where maxvalue = 'APPR')" anymore - the condition was tested against the dummy table and failed.
I believe in 7.5 that's been corrected again and in 7.1.6 or thereabouts so you can do both... however I think they are now doing three levels of testing... simple, complex: dummy table; base table... <sigh> - the right answer most likely would have been to simply use the uniqueid of the record automatically prepended to the where clause or even better, using the primarykeycolseq fields prepended to the query to ensure that a single record was returned from the db regardless of the remainder of the query...
Benefits - uses the native key indexes (preferring the primarykeycolseq as that index is most likely cached directly and the most highly tuned) and minimizes contention on the dummy (go figure, apply named in this case) table...
R/
Will
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Jason Verly
Sent: Tuesday, October 02, 2012 9:39 AM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Re: Shoud the SystemErr.log stay clear?
Ha! That explains why I see on occasion an error message related to work order history flag or a purchase order status in the error log. tyvm!
--- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>, "Hanna, Christopher CTR" <christopher.a.hanna@...<mailto:christopher.a.hanna@...>> wrote:
>
> In a perfect world, I would think that Maximo should keep the error log clean. However in the real world it's just not possible.
>
> One thing that will clutter the error logs is the use of conditional expressions. We have found that if you us them, you will consistently see false errors in the logs such as the following:
>
> java.sql.SQLException: ORA-00904: "WORKORDER"."LOCATION": invalid identifier
>
> Obviously WORKORDER.LOCATION is NOT an invalid identifier. We had a PMR to IBM and they explained it to us like this: All conditional expressions will first execute against the dummy table (for some reason I can't recall right now but didn't quite agree with) before executing against the actual object. So this is just one example of something that appears in the error log that is not actually an error.
>
> So it's unlikely that you could ever keep the error log completely clean. Moreover there is so much noise that monitoring is highly problematic. I don't even attempt to monitor the UI error logs anymore, only the MIF instance.
>
>
>
> -----Original Message-----
> From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Jason Verly
> Sent: Monday, October 01, 2012 12:00 PM
> To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
> Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
>
>
>
> This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
>
> So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
>
Great explanation Will, much better than what we got from IBM! We are in the midst of upgrading to 7.5 so I'll know soon enough if this has indeed been changed.
-----Original Message-----
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Will Hampton
Sent: Tuesday, October 02, 2012 1:06 PM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Shoud the SystemErr.log stay clear?
It has to do with trying to keep from having queries that return the whole db (dummy proofing, or ignorant proofing if your "PC")
Imagine if you ran a query that essentially was like this ":sitied = 'EAGLENA'" - when Maximo processes this and sends it to the db you get "select * from workorder where 'EAGLENA' = 'EAGLENA'" and if all your records are in the one site... you get them all...
This was a huge problem in Workflow as people didn't understand it. In version 6.2 they implemented a preprocessor that checked to see if the statement could be resolved in memory - if it could it was never sent to the db. That took care of the bulk of the problem. The above syntax wouldn't be sent to the database and the record would move along quickly.
Syntaxes that have subselects, exists or not exists clauses, etc. now are sent to the db - but you can still end up with the same problem, the subselect returns "true" and the query becomes "select * from workorder where 'APPR' in (select value from synonymdomain where maxvalue = 'APPR')" if not written properly...
In 7.1'ish someone made a rash decision and started testing against the dummy table to see if the condition was true or false and in that way they "fixed" the return the db problem... but like many decisions it was short sighted - it broke the ability to have a complex SQL statement in the where clauses - ones that have both fields AND subselects, exists, not exists etc... you couldn't write "siteid = :siteid and wonum = :wonum and :status in (select value from synonymdomain where maxvalue = 'APPR')" anymore - the condition was tested against the dummy table and failed.
I believe in 7.5 that's been corrected again and in 7.1.6 or thereabouts so you can do both... however I think they are now doing three levels of testing... simple, complex: dummy table; base table... <sigh> - the right answer most likely would have been to simply use the uniqueid of the record automatically prepended to the where clause or even better, using the primarykeycolseq fields prepended to the query to ensure that a single record was returned from the db regardless of the remainder of the query...
Benefits - uses the native key indexes (preferring the primarykeycolseq as that index is most likely cached directly and the most highly tuned) and minimizes contention on the dummy (go figure, apply named in this case) table...
R/
Will
From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of Jason Verly
Sent: Tuesday, October 02, 2012 9:39 AM
To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
Subject: [MAXIMO List] Re: Shoud the SystemErr.log stay clear?
Ha! That explains why I see on occasion an error message related to work order history flag or a purchase order status in the error log. tyvm!
--- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, "Hanna, Christopher CTR" <christopher.a.hanna@...<mailto:christopher.a.hanna@...>> wrote:
>
> In a perfect world, I would think that Maximo should keep the error log clean. However in the real world it's just not possible.
>
> One thing that will clutter the error logs is the use of conditional expressions. We have found that if you us them, you will consistently see false errors in the logs such as the following:
>
> java.sql.SQLException: ORA-00904: "WORKORDER"."LOCATION": invalid
> identifier
>
> Obviously WORKORDER.LOCATION is NOT an invalid identifier. We had a PMR to IBM and they explained it to us like this: All conditional expressions will first execute against the dummy table (for some reason I can't recall right now but didn't quite agree with) before executing against the actual object. So this is just one example of something that appears in the error log that is not actually an error.
>
> So it's unlikely that you could ever keep the error log completely clean. Moreover there is so much noise that monitoring is highly problematic. I don't even attempt to monitor the UI error logs anymore, only the MIF instance.
>
>
>
> -----Original Message-----
> From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com
> <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>]
> On Behalf Of Jason Verly
> Sent: Monday, October 01, 2012 12:00 PM
> To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> <mailto:MAXIMO%40yahoogroups.com>
> Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
>
>
>
> This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
>
> So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
>
Dude... you rock. This is awesome detail I wasn't getting when trying to troubleshoot some of the messages I was seeing in our SystemErr file. Thank you for the great post.
--- In MAXIMO@yahoogroups.com, Will Hampton <will.hampton@...> wrote:
>
> It has to do with trying to keep from having queries that return the whole db (dummy proofing, or ignorant proofing if your "PC")
>
> Imagine if you ran a query that essentially was like this ":sitied = 'EAGLENA'" - when Maximo processes this and sends it to the db you get "select * from workorder where 'EAGLENA' = 'EAGLENA'" and if all your records are in the one site... you get them all...
>
> This was a huge problem in Workflow as people didn't understand it. In version 6.2 they implemented a preprocessor that checked to see if the statement could be resolved in memory - if it could it was never sent to the db. That took care of the bulk of the problem. The above syntax wouldn't be sent to the database and the record would move along quickly.
>
> Syntaxes that have subselects, exists or not exists clauses, etc. now are sent to the db - but you can still end up with the same problem, the subselect returns "true" and the query becomes "select * from workorder where 'APPR' in (select value from synonymdomain where maxvalue = 'APPR')" if not written properly...
>
> In 7.1'ish someone made a rash decision and started testing against the dummy table to see if the condition was true or false and in that way they "fixed" the return the db problem... but like many decisions it was short sighted - it broke the ability to have a complex SQL statement in the where clauses - ones that have both fields AND subselects, exists, not exists etc... you couldn't write "siteid = :siteid and wonum = :wonum and :status in (select value from synonymdomain where maxvalue = 'APPR')" anymore - the condition was tested against the dummy table and failed.
>
> I believe in 7.5 that's been corrected again and in 7.1.6 or thereabouts so you can do both... however I think they are now doing three levels of testing... simple, complex: dummy table; base table... <sigh> - the right answer most likely would have been to simply use the uniqueid of the record automatically prepended to the where clause or even better, using the primarykeycolseq fields prepended to the query to ensure that a single record was returned from the db regardless of the remainder of the query...
>
> Benefits - uses the native key indexes (preferring the primarykeycolseq as that index is most likely cached directly and the most highly tuned) and minimizes contention on the dummy (go figure, apply named in this case) table...
>
> R/
> Will
>
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Jason Verly
> Sent: Tuesday, October 02, 2012 9:39 AM
> To: MAXIMO@yahoogroups.com
> Subject: [MAXIMO List] Re: Shoud the SystemErr.log stay clear?
>
>
>
> Ha! That explains why I see on occasion an error message related to work order history flag or a purchase order status in the error log. tyvm!
>
> --- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>, "Hanna, Christopher CTR" <christopher.a.hanna@<mailto:christopher.a.hanna@>> wrote:
> >
> > In a perfect world, I would think that Maximo should keep the error log clean. However in the real world it's just not possible.
> >
> > One thing that will clutter the error logs is the use of conditional expressions. We have found that if you us them, you will consistently see false errors in the logs such as the following:
> >
> > java.sql.SQLException: ORA-00904: "WORKORDER"."LOCATION": invalid identifier
> >
> > Obviously WORKORDER.LOCATION is NOT an invalid identifier. We had a PMR to IBM and they explained it to us like this: All conditional expressions will first execute against the dummy table (for some reason I can't recall right now but didn't quite agree with) before executing against the actual object. So this is just one example of something that appears in the error log that is not actually an error.
> >
> > So it's unlikely that you could ever keep the error log completely clean. Moreover there is so much noise that monitoring is highly problematic. I don't even attempt to monitor the UI error logs anymore, only the MIF instance.
> >
> >
> >
> > -----Original Message-----
> > From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Jason Verly
> > Sent: Monday, October 01, 2012 12:00 PM
> > To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
> > Subject: [MAXIMO List] Shoud the SystemErr.log stay clear?
> >
> >
> >
> > This is a follow-up to an internal debate with someone from IT. I was diagnosing an issue a user was having and looked at the log files with someone from IT looking over my shoulder so they could learn some background on the Maximo middleware (Websphere & SQL Server). As I was looking at the log files, I was asked why the error log file was showing faults. I said they are minor errors and not to worry about. We then entered a discussion on how do I know it's minor vs relevant to the issue.
> >
> > So... can a production Maximo install keep the SystemErr.log file clear after running for a period of time?
> >
>
>
>
>
>