[ http://issues.apache.org/jira/browse/DERBY-1221?page=comments#action_12414143 ]
Manjula Kutty commented on DERBY-1221: -------------------------------------- I ran into this problem even on a windows platform with the most recent ibm15 build. So it is not a ZOS specific problem, rather it is a jvm issue. Will be contacting the jvm people for this issue > runtimestatistics time shows large number instead of 0 with ibm15 on zOS > ------------------------------------------------------------------------ > > Key: DERBY-1221 > URL: http://issues.apache.org/jira/browse/DERBY-1221 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.1.2.3 > Environment: zOS with ibm15 > Reporter: Myrna van Lunteren > > A number of tests that printout runtimestatistics fail on zOS with ibm15, > because instead of a 'time' of 0, the time is some large number. > Tests that fail like this: > derbylang/derbylang.fail:lang/aggregateOptimization.sql > derbylang/derbylang.fail:lang/distinctElimination.sql > derbylang/derbylang.fail:lang/predicatePushdown.sql > derbylang/derbylang.fail:lang/predicatesIntoViews.sql > derbylang/derbylang.fail:lang/staleplans.sql > derbylang/derbylang.fail:lang/wisconsin.java > encryptionAll/encryption/storemats.fail:store/access.sql (in various > encryption schemes) > This is the kind of diff I see: > --------------------- > *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 *** > 2912 del > < Execute Time = 0 > 2912a2912 > > Execute Time = -3638779204078642344 > 2921 del > < next time (milliseconds) = 0 > 2921a2921 > > next time (milliseconds) = 3638779204078642344 > 2934 del > < next time (milliseconds) = 0 > 2934a2934 > > next time (milliseconds) = 3668750241784351640 > 2991 del > < Execute Time = 0 > 2991a2991 > > Execute Time = -4015137258338621104 > 3000 del > < next time (milliseconds) = 0 > 3000a3000 > > next time (milliseconds) = 4015137258338621104 > .... > ------------------------------ > As this problem occurs only with ibm15 and not with ibm14, I think somewhere > in the runtime statistics printing code we may be using BigDecimal somehow, > and it's not done in an encoding-safe way. But that is just a guess. > I'm leaving this one as Major, because it's easy to miss things when looking > through test failures this way, but I can also understand that this would be > considered minor, as apparently the paths taken by the optimizer are actually > correct and it's only the printing out that has the large numbers. Yet again > on the other hand I imagine it makes runtimestatistics less useful, with > these disconcertingly large number of milliseconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
