RE: [U2] Guaranteed unique sequential keys
>What is the most reliable way to generate unique sequential keys without >having to resort to a record on disk updated through readu/write? Sounds like you want to call a UUID generator. >The keys don't have to be contiguous but only be sortable in the order in which they >were generated by several phantom processes running concurrently. Most operating systems have a UUID generator. It will generate a 128 bit hex number guaranteed unique (at least until the year 3400) and should be sequential; but you would possibly need to convert it to sort. Under AIX this is uuid_gen and can be a VOC verb or could be called in a CGI routine if you don't want to 'execute' . > I'm currently approximating this using a concatenation of date and time with >milliseconds but I'm worried about the possibility of two phantoms generating >exactly the same key. Using a UUID (or GUID) has an advantage over something like 'time()' or even system(99) because it also guarantees that time shifts or hardware events, like crashes, leap seconds, daylight savings changes and ntp events don't interfere with unique key generation. Stuart ** 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 communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse SQL Tables
All I can offer is that it used to work in version 9.6. I haven't touched it since. Sounds like something to take up with IBM through your support provider. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Guaranteed unique sequential keys
> -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Anthony W. Youngman > Sent: Saturday, April 26, 2008 9:14 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Guaranteed unique sequential keys > > In message <[EMAIL PROTECTED]>, Glen B > <[EMAIL PROTECTED]> writes > > It's not overkill if you need a multi-app/multi-process service that > offers > >a single source for sequential keys. The other option is disk file > locking. > >Any way you look at it, you have to go to one place for the key. Don't > relay > >on O/S random numbers either. Even those are flawed at high resolution. > > Ummm > > My first reaction to this was "linux has a guaranteed true random number > generator" - the only problem is that if it runs out of randomness it > simply stops generating and anything asking for a number has to wait. > > Oh - and what do you mean by "high resolution"? I think that, if you > have a true random number generator, the chances of having a collision > approach 50% when you've used only 10% of the number space. (The classic > question about this is "how many people do you need in a room to have > even odds that two of them will share a birthday?". I think the answer > is "about 20".) > That is true and what I mean by high resolution is extremely frequent requests. The scale of that is dependant on the hardware and the application making the requests. When the entropy pool runs out, you get a function block until more hardware data is available to generate a new value. That is what I mean by "flawed". If you have a tiny box with a small entropy pool, you could exhaust the entropy pool often which could lead to performance issues. Of course, the new pseudo generators don't block at all. That is what you are referring to below. The problem there is that entropy pool is reused to generate pseudo bits to regenerate new keys from, which increases the chance of repeated keys. > But then, if you want unique, pseudo-random keys, I think there are > generators that are guaranteed to return every possible number, only > once, each cycle through the number space. > > None of this, however, solves the OP's original problem, I don't > think... > > Cheers, > Wol That's true. Random keys can not be sorted by order of creation. Glen --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control
From: Brian Leach > ...The key was to appoint someone who was responsible for it. > If it is anything more than trivial, it needs someone charged > to administer it, Conan the Librarian > not just left to the whims of developers!... Which brings us to the 2nd key: Build in perks for the developers for using version control. It shouldn't be another layer of management that slows them down. Properly implemented, it should be a programmer productivity tool. The more that it helps them be able to compare versions, track what change happened when & by whom, lump & segregate work, coordinate activity between programmers, do status reporting . . ., the more it directly helps programmers do those tasks, the more enthusiastic they will be, & the less likely to circumvent or resent enforcement. I recall implementing it one time where the practice had been to never delete old code, just comment it out and surround changes with date and project numbers comment lines. It got so that a source file had more commented out stuff than actual compilable code. Very difficult to read. When we implemented version control, I suggested that this practice was no longer necessary because they could easily reconstruct pretty pictures of change history. They insisted on doing it the old way, too. Several months later the staff violently revolted against their own conservatism and wanted a special internal project just to clean out all that old stuff because version control was so good to them. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse SQL Tables
I modified my test to also include ICHECK - curiously enough, this does not report any errors either. It is starting to look like OPENCHECK/WRITE and ICHECK do not consider column data type as a CONSTRAINT - sort of defeats one of the main benfits of SQL tables doesn't it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of u2ug Sent: April 28, 2008 8:54 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniVerse SQL Tables Yes I know about the OPENCHECK config setting which was why I was intentionally using the OPENCHECK statement. What you are saying seems to agree with how I thought things should work, however, even when using OPENCHECK, I am able to write complete garbage to an SQL table column defined as a DATE type. The hope is that we can SQL'ize tables to allow us to setup SQL security constraints for odbc access without affecting any existing data or code. Bad data we can get around by configuring the dictionaries accordingly but having existing code bomb due to bad data is not an option. I tested using OPENCHECK because a normal write didn't cause an error but OPENCHECK should have, just to ensure that the system was working as it should - seems it isn't and that is a concern. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: April 28, 2008 3:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse SQL Tables OPENCHK is also a parameter in uvconfig. It allows you to configure the system to bypass integrity checks when the file is opened with OPEN - but not when the file is opened with OPENCHK. Thus your understanding is conditionally correct, depending on the setting of OPENCHK in uvconfig. This is not new, it has been thus since SQL was added to UniVerse BASIC. This "feature" is intended for the transition period, until you have cleaned up the legacy data (!). Once you have done that, you can "switch off" the loophole via the OPENCHK configuration parameter and you will never again have data written into your table that fails any of your security or integrity checks, including data type. There is also a function called ICHECK() that allows you to perform a "trial write". It reports whether the write will or will not violate a constraint, and returns information about which one would be violated. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse SQL Tables
Well that it the point - as I stated in my original post, I have written a test program that demonstrates that data type constraint checks are not being performed even though the OPENCHECK statement is being used. Hence the concern. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clifton Oliver Sent: April 28, 2008 2:59 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse SQL Tables Not unless you've written a ten line test program to prove that. On Apr 27, 2008, at 10:50 PM, u2ug wrote: > Can we safely assume that any file writes on sql tables are not > subject > to data type checks or will this pop up to bite us at some point ? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse SQL Tables
Yes I know about the OPENCHECK config setting which was why I was intentionally using the OPENCHECK statement. What you are saying seems to agree with how I thought things should work, however, even when using OPENCHECK, I am able to write complete garbage to an SQL table column defined as a DATE type. The hope is that we can SQL'ize tables to allow us to setup SQL security constraints for odbc access without affecting any existing data or code. Bad data we can get around by configuring the dictionaries accordingly but having existing code bomb due to bad data is not an option. I tested using OPENCHECK because a normal write didn't cause an error but OPENCHECK should have, just to ensure that the system was working as it should - seems it isn't and that is a concern. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: April 28, 2008 3:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse SQL Tables OPENCHK is also a parameter in uvconfig. It allows you to configure the system to bypass integrity checks when the file is opened with OPEN - but not when the file is opened with OPENCHK. Thus your understanding is conditionally correct, depending on the setting of OPENCHK in uvconfig. This is not new, it has been thus since SQL was added to UniVerse BASIC. This "feature" is intended for the transition period, until you have cleaned up the legacy data (!). Once you have done that, you can "switch off" the loophole via the OPENCHK configuration parameter and you will never again have data written into your table that fails any of your security or integrity checks, including data type. There is also a function called ICHECK() that allows you to perform a "trial write". It reports whether the write will or will not violate a constraint, and returns information about which one would be violated. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse SQL Tables
Not unless you've written a ten line test program to prove that. On Apr 27, 2008, at 10:50 PM, u2ug wrote: Can we safely assume that any file writes on sql tables are not subject to data type checks or will this pop up to bite us at some point ? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse SQL Tables
OPENCHK is also a parameter in uvconfig. It allows you to configure the system to bypass integrity checks when the file is opened with OPEN - but not when the file is opened with OPENCHK. Thus your understanding is conditionally correct, depending on the setting of OPENCHK in uvconfig. This is not new, it has been thus since SQL was added to UniVerse BASIC. This "feature" is intended for the transition period, until you have cleaned up the legacy data (!). Once you have done that, you can "switch off" the loophole via the OPENCHK configuration parameter and you will never again have data written into your table that fails any of your security or integrity checks, including data type. There is also a function called ICHECK() that allows you to perform a "trial write". It reports whether the write will or will not violate a constraint, and returns information about which one would be violated. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse SQL Tables
Not unless you've written a ten line test program to prove that. On Apr 27, 2008, at 10:50 PM, u2ug wrote: Can we safely assume that any file writes on sql tables are not subject to data type checks or will this pop up to bite us at some point ? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
