RE: Timestamp
Hi Ken, At 07:56 PM 28/04/2004, Ken Wallis wrote: Of course one could easily write a FUNCTION that concatenated DATE() and TIME() and used named common to keep track of the last value it gave out to decide if it needed to add an alpha character and if so, which one, but that What about SYSTEM(12) instead of TIME() ? would only be unique inside the user's session, not system wide. If you wanted something that was unique system wide, you might need to go slightly further than one alpha character and you'd need to involve writing something away to a file (or at least locking something) to get coordination between sessions, and there'd be an overhead associated with that of course. Would be much better to have a record in a control file that is regularly incremented. ie in pseudo code: READU COUNTER FROM CONTROL, COUNTERNAME; COUNTER +=1; WRITE COUNTER TO CONTROL,COUNTERNAME ...use COUNTER as you unique id It would also be quite trivial to knock up a CALLC function that obtained the value returned by the time() C runtime function which gives the number of seconds since somewhere in 1970. Computationally that would be the most efficient, but again, it wouldn't be unique system wide. You should have Use CALLC to solve your problem in your sig to save typing it every day. ;-) - Robert -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Timestamp
Bill H. wrote on 04/28/2004 12:27:30 AM: SYSTEM(19) on D3: Returns a unique item-id consisting of the current system date in internal format, followed immediately by the current system time in seconds. If more than one item-id is generated in a second, an alpha character is appended to the item-id. The best way to simulate this - on UniData, UniVerse, or indeed on D3 - is to roll your own solution that doesn't involve contention. When I was working on a Sequoia Pick system we used SYSTEM(19) rather extensively. It was an easy way for multiple processes to generate unique keys to a file. We thought it was a great way to avoid the bottleneck created by a next key record in a control file. We knew that having multiple processes banging against a single locked record was a bottleneck and we pounced upon this wonderful thing called SYSTEM(19). What a wonderful way to avoid bottlenecks. I was young - well younger - then, and didn't understand the way UNIX worked. There was just this magical facility available, so it was used with abandon. It seemed to be the answer to our problems. Then we saw that the system started crawling and, after much work, came to the conclusion that the processes using SYSTEM(19) were the cause. That's when I started learning UNIX terms like semaphore. In other words, when you're guaranteeing uniqueness system-wide, you're going to have to bind on something. That was lesson #1. Lesson 2 reared its ugly head when we were suddenly missing records during a batch update process. After tearing the application apart, and scrutinizing everything including the IDs of the records in a transaction file, we finally discovered that we were over-writing records. As Bill H. mentioned, the date and time was suffixed with a single character. If I recall correctly, they started with the letter A, then incrimented from there. I think when they got to Z they started with numerals. They might have also included some non-alpha-numeric characters. But with 1200 users on a 16-CPU system, there were times when we used all of the available characters in a second, and it started back at the beginning. We were just blindly writing records with SYSTEM(19) as the key, so earlier records within a second were being overwritten by later records within the same second. Clearly, SYSTEM(19) wasn't the best approach. Since we didn't care about the contents of the ID - only system-wide uniqueness - we started using something like this: date*time*port*seqno where date and time represented the beginning of the current process and seqno was a number incremented within the program. This was guaranteed to be unique system-wide. To our great surprise and pleasure, performance also went through the roof, since there was no longer any chance for a bottleneck. So, as a long answer to Eugene's short question - with some old codger reminiscence mixed in - no, SYSTEM(19) isn't available on UniData. Rejoice! Tim Snyder IBM Data Management Solutions Consulting I/T Specialist , U2 Professional Services [EMAIL PROTECTED] u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Timestamp
All, How about the following (86400 * DATE()) + TIME()):.:GETPID()?. You could use common to check that (86400 * DATE()) + TIME()) is unique within the process, and should probably check that the date has not changed between calling DATE and TIME. This would be unique system wide I believe. Regards, Phil Walker +64 21 336294 [EMAIL PROTECTED] infocusp limited \\ PO Box 77032, Auckland New Zealand \ www.infocusp.co.nz DISCLAIMER: This electronic message together with any attachments is confidential. If you are not the intended recipient, do not copy, disclose or use the contents in any way. Please also advise us by return e-mail that you have received the message and then please destroy. infocusp limited is not responsible for any changes made to this message and / or any attachments after sending by infocusp limited. We use virus scanning software but exclude all liability for viruses or anything similar in this email or any attachment -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Colquhoun Sent: Thursday, April 29, 2004 1:23 AM To: U2 Users Discussion List Subject: RE: Timestamp Hi Ken, At 07:56 PM 28/04/2004, Ken Wallis wrote: Of course one could easily write a FUNCTION that concatenated DATE() and TIME() and used named common to keep track of the last value it gave out to decide if it needed to add an alpha character and if so, which one, but that What about SYSTEM(12) instead of TIME() ? would only be unique inside the user's session, not system wide. If you wanted something that was unique system wide, you might need to go slightly further than one alpha character and you'd need to involve writing something away to a file (or at least locking something) to get coordination between sessions, and there'd be an overhead associated with that of course. Would be much better to have a record in a control file that is regularly incremented. ie in pseudo code: READU COUNTER FROM CONTROL, COUNTERNAME; COUNTER +=1; WRITE COUNTER TO CONTROL,COUNTERNAME ...use COUNTER as you unique id It would also be quite trivial to knock up a CALLC function that obtained the value returned by the time() C runtime function which gives the number of seconds since somewhere in 1970. Computationally that would be the most efficient, but again, it wouldn't be unique system wide. You should have Use CALLC to solve your problem in your sig to save typing it every day. ;-) - Robert -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Timestamp
For those not familiar: SYSTEM(19) on D3: Returns a unique item-id consisting of the current system date in internal format, followed immediately by the current system time in seconds. If more than one item-id is generated in a second, an alpha character is appended to the item-id. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eugene Perry Sent: Tuesday, April 27, 2004 8:06 PM To: [EMAIL PROTECTED] Subject: Timestamp Hello, On Unidata, is there an equivalent of D3's SYSTEM(19)? Thanks Eugene -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
