EnterpriseOne (E1) Batch Job Runtimes

4 thoughts on “EnterpriseOne (E1) Batch Job Runtimes”

1. This SQL doesn’t work quite correctly. I’m not sure about where you live, but where I live there are only 60 seconds in a minute, 60 seconds in an hour and 24 hours in a day. Your calculation for Runtime conveniently ignores these facts, resulting in wildly incorrect results (your calculation assumes 100 seconds per minute, and 100 minutes per hour).

   For instance, a job starts at 5:00:28 AM and ends at 8:10:39 PM. According to your calculations, the runtime is 31,011 seconds (8 hours, 36 minutes, 51 seconds). In fact, the runtime for this job is 11,411 seconds (3 hours, 10 minutes, 11 seconds).

   An easier solution would be to convert the JDE time to a Time the AS/400 understands, then use built-in functions to calculate the elapsed time. Or you could do all the calculations in SQL, but to get correct results you’d better remember how many hours, minutes and seconds are in a day.

   Just for reference, you can’t subtract JDE dates to get number of days, either, since there are only 365 days in a year (not the 999 allowed by JDE dates).

   Reply

2. Hmmm…

   Thanks for the comment, I think

   First of all, I’m not sure if I should take this as an insult or just a comment from an over worked information technology colleague. Either way, the first paragraph was fairly harsh.

   Now, lets get to the concerns you pointed out between your attempts at put-downs.

   I’m not sure if you noticed but, I never said that the result was in seconds. In fact, take a look at your example:Job start time = 5:00:28 AMJob end time = 8:10:39 PMThe answer to this is actually 15 hours, 10 minutes, 11 seconds.
   Assuming this was a typo, lets look at the following:

   Job start time = 5:00:28 PM
   Job end time = 8:10:39 PM

   The answer that you would come up with in the SQL is 31011. Looking at this
   result from
   an EnterpriseOne point-of-view, this would translate to 3 hours, 10 minutes, 11
   seconds. Which just so happens to be what you came up with.
   The easier solution…

   If you read the whole post, you may have seen that that is exactly what I did in
   the second SQL. 
   I used the TIMESTAMP function as in lines 9
   and 12 above.
   Just for reference…

   This issue was the whole reason for the second SQL. “the problem comes in
   when you have a job that runs over 235959”, meaning 11:59:59 PM.

   Thanks for the comment Bill. I’m not sure if you were having a bad day when
   you saw this SQL or what but, next time when you comment on my blog don’t insinuate
   incompetence. I make mistakes, just like the next guy, and appreciate it when
   they are pointed out with some CLASS.

   Reply

3. I think you need to be careful when you say “Take the last action time and subtract the submit time “.. that is only accurate if the job never waited in a queue. I’ve had jobs where the submit time is 10 hours from the last action time, but the job really only took 2 minutes to run, but was stuck waiting in the queue..

   The only way I found to know for sure is look at the joblog, which gives you an accurate start time. Of course, that means there’s no easy way to query it..

   Thoughts?

   Just found this, I’m enjoying the blog!

   Reply

4. Hey, Bob.

   You are correct. That is a pretty big assumption that the job would not have waited in the queue. Unfortunately, like you said, there isn’t really any other way to easily query it.

   Any suggestions for a better way to do it would be greatly appreciated.

   Thanks for the comment!

   Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.