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
ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970)
unix generally keeps track of time as number of seconds past midnight GMT, Jan 1, 1970. Is there a conversion code to convert that to from external date time? If not, have you already written a custom conversion care to share? (I am NOT asking how to roll my own. I just don't want to do so if someone already has it, including figuring out flexability in output format.) Chuck Stevenson -- 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: ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970)
seconds past midnight GMT, Jan 1, 1970. Is there a conversion code yeah .. something like: pick DATE() = INT(unixtime/86400)+732 pick TIME() = MOD(unixtime,86400) which makes: unixtime = (pick DATE() - 732) * 86400 + pick TIME() and PICK time is always local time, not GMT -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: ICONV/OCONV for unix internal timestamp (secs past 00:0001/01/1970)
Sorry, no cigar. That's not a conversion code that you can stick in 3 of a dictionary D-item, or 7 of an A-item. Or as second argument of either, nay, both ICONV() OCONV(). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Mongiovi Sent: Wednesday, April 28, 2004 12:43 PM To: U2 Users Discussion List Subject: RE: ICONV/OCONV for unix internal timestamp (secs past 00:0001/01/1970) seconds past midnight GMT, Jan 1, 1970. Is there a conversion code yeah .. something like: pick DATE() = INT(unixtime/86400)+732 pick TIME() = MOD(unixtime,86400) which makes: unixtime = (pick DATE() - 732) * 86400 + pick TIME() and PICK time is always local time, not GMT -- 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: ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970)
Are you asking about the 'MTHS' conversion code? - Original Message - From: Stevenson, Charles [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 1:47 PM Subject: ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970) unix generally keeps track of time as number of seconds past midnight GMT, Jan 1, 1970. Is there a conversion code to convert that to from external date time? If not, have you already written a custom conversion care to share? (I am NOT asking how to roll my own. I just don't want to do so if someone already has it, including figuring out flexability in output format.) Chuck Stevenson -- 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: ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970)
Chuck, you need to worry about time zone when rendering the unix epoch time as it is UTC (aka GMT) based. A simple conversion of the unix epoch time to U2 date/time will be incorrect unless you are in Britain in the winter - and who'd be there then ;-) Have a look at http://www.pickwiki.com/cgi-bin/wiki.pl?DateUtility . DateUtility(parseEpochTime,intTimeStamp) will return U2 Date Time based on the local machine time zone. This function could be used as a conversion by wrapping it and globally cataloguing it as $ParseEpochTime OCONV(intTimeStamp,'UParseEpochTime') Cheers, Stuart -Original Message- Behalf Of Stevenson, Charles unix generally keeps track of time as number of seconds past midnight GMT, Jan 1, 1970. Is there a conversion code to convert that to from external date time? If not, have you already written a custom conversion care to share? (I am NOT asking how to roll my own. I just don't want to do so if someone already has it, including figuring out flexability in output format.) Chuck Stevenson ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: ICONV/OCONV for unix internal timestamp (secs past 00:00 01/01/1970)
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart Boydell Have a look at http://www.pickwiki.com/cgi-bin/wiki.pl?DateUtility . DateUtility(parseEpochTime,intTimeStamp) will return U2 Date Time based on the local machine time zone. Now that's rich. There's a lot there. Looks like maybe good to piggyback on it. thanks, cds -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: ICONV/OCONV for unix internal timestamp (secspast00:0001/01/1970)
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Why not write a user conversion code that does this calculation as a Uname conversion? That's what I was asking, if anyone already did it. I'd prefer it to be flexible enough to allow various oconv formats and to iconv various strings. For example, what if you just have date don't care about time, etc. Plus it ought to have the property analogous to that of D conversions where: ICONV( OCONV( idate, 'D' ), 'D' ) = idate (What's the set theory word for that property, where each member of a set can be transformed to a corresponding member of another set, and the inverse transformation will always get you back to your starting point? Reflexive? That doesn't sound right. It's late, gimme a break.) -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
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
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
RE: COUNT modifying unix timestamp
Is there any way to directly access information stored in the file header? I use the information returned by the FILE.USAGE command to determine if a static file can be archived or if it needs to be checked to see if it needs to be resized. Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 9:18 AM To: U2 Users Discussion List; U2 Users Discussion List Subject: Re: COUNT modifying unix timestamp Actually, it was added in during release 7.x of uniVerse to support the SQL optimizer. The optimizer used the count to make a determination on how long it would take to perform certain SQL operations such as outer-joins, etc, and spit out a warning message something like It will take 4307 hours to perform this operation. Do you want to continue?. At first, only an unqualified COUNT command (i.e. COUNT FILE) would update this field, but sometime in early 8.x releases, I added the code into uvbackup/uvrestore so that it would also update this field. That was quite a few years ago so I don't have the exact timeframes, but there ya go Glenn At 04:54 AM 02/17/2004, Martin Phillips wrote: Apologies if I missed anyone already giving this explanation... The other thing, of course, which timestamp? Date modified, or date accessed? Are you sure your client isn't looking at the wrong one? UniVerse file system revision 12 which came in at release 9.5 includes a count of records in the file header for use by uvbackup and uvrestore. This is updated by COUNT and by uvbackup itself (perhaps other places too). Maybe it's time for another plug for the UniVerse Internals course where these things get discussed??? Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 -- 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 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: COUNT modifying unix timestamp
I believe there is. There is a UNIVERSE.INCLUDE file FILEINFO.H which includes a definition of what would be in each dynamic array field when using: FILEINFO(Fvar, 99) or FILEINFO(Fvar, FINFO$HDRLAYOUT) For example if you executed: FileInfo = FILEINFO(Fvar, 99) you'd have: FileInfo1 = File revision level FileInfo2 = Modulus FileInfo3 = Separation etc etc etc The count field updated in the file header would be FileInfo112. Note that some fields are bitmapped and none of that is detailed. Each of the fields makes more sense if you know what actually exists within a universe file header. I know there is documentation out there ;-) At 02:11 PM 02/18/2004, you wrote: Is there any way to directly access information stored in the file header? I use the information returned by the FILE.USAGE command to determine if a static file can be archived or if it needs to be checked to see if it needs to be resized. Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 9:18 AM To: U2 Users Discussion List; U2 Users Discussion List Subject: Re: COUNT modifying unix timestamp Actually, it was added in during release 7.x of uniVerse to support the SQL optimizer. The optimizer used the count to make a determination on how long it would take to perform certain SQL operations such as outer-joins, etc, and spit out a warning message something like It will take 4307 hours to perform this operation. Do you want to continue?. At first, only an unqualified COUNT command (i.e. COUNT FILE) would update this field, but sometime in early 8.x releases, I added the code into uvbackup/uvrestore so that it would also update this field. That was quite a few years ago so I don't have the exact timeframes, but there ya go Glenn At 04:54 AM 02/17/2004, Martin Phillips wrote: Apologies if I missed anyone already giving this explanation... The other thing, of course, which timestamp? Date modified, or date accessed? Are you sure your client isn't looking at the wrong one? UniVerse file system revision 12 which came in at release 9.5 includes a count of records in the file header for use by uvbackup and uvrestore. This is updated by COUNT and by uvbackup itself (perhaps other places too). Maybe it's time for another plug for the UniVerse Internals course where these things get discussed??? Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 -- 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 -- 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: COUNT modifying unix timestamp
Cool. I found the include file with the following comment: * 04/23/99 24742 GMH Add special FINFO$HDRLAYOUT and access keywords ;-) But my include file only includes keys up to the following line: EQUATE FH$RESIZEPATH TO 95 I am running 9.6. Were the extra keys added in a later release or do I just need to search for additional documentation? Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Glenn Herbert Sent: Wednesday, February 18, 2004 2:28 PM To: U2 Users Discussion List Subject: RE: COUNT modifying unix timestamp I believe there is. There is a UNIVERSE.INCLUDE file FILEINFO.H which includes a definition of what would be in each dynamic array field when using: FILEINFO(Fvar, 99) or FILEINFO(Fvar, FINFO$HDRLAYOUT) For example if you executed: FileInfo = FILEINFO(Fvar, 99) you'd have: FileInfo1 = File revision level FileInfo2 = Modulus FileInfo3 = Separation etc etc etc The count field updated in the file header would be FileInfo112. Note that some fields are bitmapped and none of that is detailed. Each of the fields makes more sense if you know what actually exists within a universe file header. I know there is documentation out there ;-) At 02:11 PM 02/18/2004, you wrote: Is there any way to directly access information stored in the file header? I use the information returned by the FILE.USAGE command to determine if a static file can be archived or if it needs to be checked to see if it needs to be resized. Vance -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: COUNT modifying unix timestamp
Actually, it was added in during release 7.x of uniVerse to support the SQL optimizer. The optimizer used the count to make a determination on how long it would take to perform certain SQL operations such as outer-joins, etc, and spit out a warning message something like It will take 4307 hours to perform this operation. Do you want to continue?. At first, only an unqualified COUNT command (i.e. COUNT FILE) would update this field, but sometime in early 8.x releases, I added the code into uvbackup/uvrestore so that it would also update this field. That was quite a few years ago so I don't have the exact timeframes, but there ya go Glenn At 04:54 AM 02/17/2004, Martin Phillips wrote: Apologies if I missed anyone already giving this explanation... The other thing, of course, which timestamp? Date modified, or date accessed? Are you sure your client isn't looking at the wrong one? UniVerse file system revision 12 which came in at release 9.5 includes a count of records in the file header for use by uvbackup and uvrestore. This is updated by COUNT and by uvbackup itself (perhaps other places too). Maybe it's time for another plug for the UniVerse Internals course where these things get discussed??? Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 -- 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
COUNT modifying unix timestamp
We have a client running UV 10.0.16 on HPUX 11i who has noted that a Universe COUNT will modify the unix timestamp of a file. Has this always been the case? Why does a supposedly read-only operation like COUNT modify the timestamp but others such as LIST, SORT, etc. don't? Cheers, David Eves -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: COUNT modifying unix timestamp
You don't mention the file type, but I am assuming it is a dynamic file. If it is, this is normal. I recall the first release of reliable dynamic files had the feature of disallowing access to users without 'read and write' permission...which wasn't actually documented anywhere...ouch! I think you will find 'LIST' and other 'read-only' commands has the same effect. Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eves, David Sent: Tuesday, February 17, 2004 9:40 AM To: U2 Users Discussion List Subject: COUNT modifying unix timestamp We have a client running UV 10.0.16 on HPUX 11i who has noted that a Universe COUNT will modify the unix timestamp of a file. Has this always been the case? Why does a supposedly read-only operation like COUNT modify the timestamp but others such as LIST, SORT, etc. don't? Cheers, David Eves -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
unclassified RE: COUNT modifying Unix timestamp
David, I see the same effect on UV 10.0.15 on Win2K3 for Dynamic files, also for Dictionaries (type 3). LIST a file: no change to Windows file timestamp. COUNT the same file: Windows file timestamp is updated. ! Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eves, David Sent: Tuesday, February 17, 2004 9:40 AM To: U2 Users Discussion List Subject: COUNT modifying Unix timestamp We have a client running UV 10.0.16 on HPUX 11i who has noted that a Universe COUNT will modify the Unix timestamp of a file. Has this always been the case? Why does a supposedly read-only operation like COUNT modify the timestamp but others such as LIST, SORT, etc. don't? Cheers, David Eves The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
