It is because Google preserves the time stamp of the email when it was received, but it won’t actually go out until it is approved. The timestamps are correct.
jim *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Charlie Noah *Sent:* Wednesday, August 17, 2011 1:42 PM *To:* [email protected] *Subject:* Re: jbase problems show-items-locks Hi VK, Would you mind checking your time settings in your email client (or perhaps the problem is with your ISP's email server)? This email arrived a few minutes ago with a time stamp of 08:53 (I got it at approximately 15:33 CST, United States), and appeared way up in my inbox, which is sorted by date/time. Just a nit, I know, but I get a lot of these, especially from across the pond. ;^) Thanks, Charlie Noah On 08-17-2011 8:53 AM, VK wrote: Hi John, What about a thought of changing the whole scheme of agents' work? Like: starting a job (on a SELECT stage) "main" process creates not a single F.JOB.LIST file but several ones - each for one agent to use exclusively. Of course situation of dying agent is to be handled as well (as well as parallel execution of different jobs). But I believe finally we might achieve better overall performance. Offtopic: Another thing that I personally would like to see in T24 COB - you can set number of agents for particular time but not for particular job... (you know sometimes it has to be only one) VK On Aug 17, 11:51 am, John Watson <[email protected]> <[email protected]> wrote: Hi Adrian, My understanding is that when a JR file feels the need to grow there will be a group lock in place to secure the re-distributed data from that group and for the new target groups. The duration of the lock may seem quite lengthy as the entire re-distribution must happen before the lock is released - are you seeing the group locks only in files with growth? I can see a benefit in the JR files for Non-Stop etc. but as with everything there is a cost - in this case possibly performance. I'm sure it has been said many times here before that a well sized hash file will outperform most types of file storage. Cheers, John. On Aug 16, 7:53 am, adrian <[email protected]> <[email protected]> wrote: Jim, Thanks for your reply, what is happening is that when these blank keys locks show in show-item-locks the throughput of the system is hit bady. Also noticed that the more locks a transaction makes then the blank keys start appearing. Is is then the problem that the JR files group lock? Never seen blank keys before unless there is a bug in the code, but this is happening for almost all T24 applications (high volume) loads, with more than 4 file locks. We are using mostly JR type files with some J4 files. AA On Aug 15, 1:31 pm, Jim Idle <[email protected]> <[email protected]> wrote: -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
