RE: [U2] Guaranteed unique sequential keys
Thank you all for all the responses. I was hoping that somewhere within the operating system's scheduling mechanism there is something like a timeslice serial number which could be read with some system function. No 2 processes could ever return the same timeslice serial number within a day for example. My unique id would then be formed as follows: snip BASEKEY = DATE():*:time slice serial number IF BASEKEY EQ PREVBASEKEY THEN SEQ.NUM += 1 ELSE PREVBASEKEY = BASEKEY SEQ.NUM = 1 END UNIQUE.KEY = BASEKEY:*:SEQ.NUM /snip This way there would be no need for extra IOs and no bottlenecks on a syncronisation key. --- On Fri, 25/4/08, Glen B [EMAIL PROTECTED] wrote: From: Glen B [EMAIL PROTECTED] Subject: RE: [U2] Guaranteed unique sequential keys To: u2-users@listserver.u2ug.org Date: Friday, 25 April, 2008, 5:30 AM You'll need a central key generator to manage high resolution sortable sequential keys. You can use whatever connection medium is feasible and let a single process/phantom generate the keys in numerical order. The problem with using a key generator like this is that you could easily produce a bottleneck. On the other hand, the benefit of doing it this way is that the generator can be a single phantom. It can keep track of the last used key in memory and can pregenerate keys for near-future or parallel usage. If the connection medium you choose allows for multiple requests at a time, then your management code must be able to manage and pregenerate keys for each thread concurrently. A wide solution could be a socket service that serves unique keys to clients. I use base-16 for a lot of sequential keys so that I have many unique iterations per key length. I always use them as direct pointers and I never sort them, though. Hex sortability from LIST/SORT/SELECT could be questionable. Glen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marco Manyevere Sent: Thursday, April 24, 2008 5:55 AM To: u2-users@listserver.u2ug.org Subject: [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? 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. I'm currently approximating this using a concatenation of date and time with millisecondsB but I'm worried about the possibility of two phantoms generating exactly the same key. B Although no collision has been detected so far, I have added an extra check where after generating the key I first test if a record with that key exists. If so IB increment and append aB serial number and repeat the test until aB unique key is found. ItB seems to be working well but I still think there is a better way to do this. B Thanks for any help. B Marco. __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html --- 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/ _ Yahoo! For Good. Give and get cool things for free, reduce waste and help our planet. Plus find hidden Yahoo! treasure --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Guaranteed unique sequential keys
Apologies if this has already been said but I have not been following this thread too closely. D3 has a SYSTEM(19) function that does what you are wanting, returning the date/time with a suffix added if any user has already generated the same key. Unfortunately, UV implements SYSTEM(19) as something different. It should not be too difficult to do this using the GCI mechanism. The actual code to do this is simple (we recently implemented SYSTEM(19) in QM and it took only a few minutes to do). The code needs to maintain a shared memory record of the last timestamp value for which it was called and the suffix if one was added. Then, using a semaphore to ensure that it is single threaded, a call to the GCI function would create the new key, updating the shared memory. I admit to never having written a UV GCI function but the documention seems to suggest that it is easy. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Guaranteed unique sequential keys
Since we're talking OOB (out of box) why not try the user semaphore locking that is built into the system. Check the BASIC LOCK and UNLOCK , and LIST.LOCKS in tcl. Your process cant write until it can lock. It writes, then unlocks. and so on. j On 4/25/08, Marco Manyevere [EMAIL PROTECTED] wrote: Thank you all for all the responses. I was hoping that somewhere within the operating system's scheduling mechanism there is something like a timeslice serial number which could be read with some system function. No 2 processes could ever return the same timeslice serial number within a day for example. My unique id would then be formed as follows: snip BASEKEY = DATE():*:time slice serial number IF BASEKEY EQ PREVBASEKEY THEN SEQ.NUM += 1 ELSE PREVBASEKEY = BASEKEY SEQ.NUM = 1 END UNIQUE.KEY = BASEKEY:*:SEQ.NUM /snip This way there would be no need for extra IOs and no bottlenecks on a syncronisation key. --- On Fri, 25/4/08, Glen B [EMAIL PROTECTED] wrote: From: Glen B [EMAIL PROTECTED] Subject: RE: [U2] Guaranteed unique sequential keys To: u2-users@listserver.u2ug.org Date: Friday, 25 April, 2008, 5:30 AM You'll need a central key generator to manage high resolution sortable sequential keys. You can use whatever connection medium is feasible and let a single process/phantom generate the keys in numerical order. The problem with using a key generator like this is that you could easily produce a bottleneck. On the other hand, the benefit of doing it this way is that the generator can be a single phantom. It can keep track of the last used key in memory and can pregenerate keys for near-future or parallel usage. If the connection medium you choose allows for multiple requests at a time, then your management code must be able to manage and pregenerate keys for each thread concurrently. A wide solution could be a socket service that serves unique keys to clients. I use base-16 for a lot of sequential keys so that I have many unique iterations per key length. I always use them as direct pointers and I never sort them, though. Hex sortability from LIST/SORT/SELECT could be questionable. Glen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marco Manyevere Sent: Thursday, April 24, 2008 5:55 AM To: u2-users@listserver.u2ug.org Subject: [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? 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. I'm currently approximating this using a concatenation of date and time with millisecondsB but I'm worried about the possibility of two phantoms generating exactly the same key. B Although no collision has been detected so far, I have added an extra check where after generating the key I first test if a record with that key exists. If so IB increment and append aB serial number and repeat the test until aB unique key is found. ItB seems to be working well but I still think there is a better way to do this. B Thanks for any help. B Marco. __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html --- 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/ _ Yahoo! For Good. Give and get cool things for free, reduce waste and help our planet. Plus find hidden Yahoo! treasure --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- john --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Guaranteed unique sequential keys
On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere [EMAIL PROTECTED] wrote: Thank you all for all the responses. Marco, One last thought looking at your OP for a non-disk IO locking function, I don't see how you can avoid disk IO unless there is some kind of of in-memory locking process. There may be a kernel option you could use but I'm not a c programmer so can't say. In bash I have seen a lot of the classic test/touch but this can lead to race conditions and a symlink is a more robust solution. However, I'm not sure running a ln -s command at the OS level is going to be faster than a readu (and I can't see from your posts if you are on a *nix platform and even have that option). So... in the best traditions of using a pile-driver to crack a nut you could roll your own . Of the top of my head, a locking service would be a U2 subroutine listening on a particular network port that is started/stopped along with the DB. Your client routines would use the socket functions to connect. The nice thing is you get the duplicate connection handling for free. U2 socket listeners are not multi-threaded so the first client in gets the socket. As long as you hold it for 1 clock tick before closing and have the other clients on a time-out longer than 1 clock-tick, you should get your unique keys. I did mention this was over-kill right? Although the code itself is pretty simple and, in my experience on Unidata, the U2 sockets routines work very well, I would spend some time benchmarking to make sure this kind of effort is worthwhile. Assuming you have some spare server capacity, if the phantoms are using a lock file on a frequent basis, the file will likely be in cache anyway. HTH but probably not. Adrian I was hoping that somewhere within the operating system's scheduling mechanism there is something like a timeslice serial number which could be read with some system function. No 2 processes could ever return the same timeslice serial number within a day for example. My unique id would then be formed as follows: snip BASEKEY = DATE():*:time slice serial number IF BASEKEY EQ PREVBASEKEY THEN SEQ.NUM += 1 ELSE PREVBASEKEY = BASEKEY SEQ.NUM = 1 END UNIQUE.KEY = BASEKEY:*:SEQ.NUM /snip This way there would be no need for extra IOs and no bottlenecks on a syncronisation key. --- On Fri, 25/4/08, Glen B [EMAIL PROTECTED] wrote: From: Glen B [EMAIL PROTECTED] Subject: RE: [U2] Guaranteed unique sequential keys To: u2-users@listserver.u2ug.org Date: Friday, 25 April, 2008, 5:30 AM You'll need a central key generator to manage high resolution sortable sequential keys. You can use whatever connection medium is feasible and let a single process/phantom generate the keys in numerical order. The problem with using a key generator like this is that you could easily produce a bottleneck. On the other hand, the benefit of doing it this way is that the generator can be a single phantom. It can keep track of the last used key in memory and can pregenerate keys for near-future or parallel usage. If the connection medium you choose allows for multiple requests at a time, then your management code must be able to manage and pregenerate keys for each thread concurrently. A wide solution could be a socket service that serves unique keys to clients. I use base-16 for a lot of sequential keys so that I have many unique iterations per key length. I always use them as direct pointers and I never sort them, though. Hex sortability from LIST/SORT/SELECT could be questionable. Glen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marco Manyevere Sent: Thursday, April 24, 2008 5:55 AM To: u2-users@listserver.u2ug.org Subject: [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? 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. I'm currently approximating this using a concatenation of date and time with millisecondsB but I'm worried about the possibility of two phantoms generating exactly the same key. B Although no collision has been detected so far, I have added an extra check where after generating the key I first test if a record with that key exists. If so IB increment and append aB serial number and repeat the test until aB unique key is found. ItB seems to be working well but I still think there is a better way to do this. B Thanks for any help. B Marco. __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html --- u2-users mailing list u2-users@listserver.u2ug.org To
RE: [U2] Corrupt file
The fix worked beautifully and quick too. Thank you very much for your assistance. I have added your procedure to our notes for future reference. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Alfke Sent: Thursday, April 24, 2008 9:36 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Corrupt file Wyatt; guide and verify2 simply find the corruption. dumpgroup/fixgroup and fixfile are used to correct the file. fixfile takes the output from guide and does it's own dumpgroup and fixgroup. I use dump/fixgroup mostly because I like to see what's happening. My steps: 1. get exclusive access to the file 2. create OS level copy of the file 3. use RECORD to get the other items in the group (RECORD OPEN.MO 082352500) within UniData 4. Dump the group (DUMPGROUP OPEN.MO 1327 -dopenmo1327) from the OS prompt 5. Fix the group (FIXGROUP OPEN.MO 1327 -iopenmo1327) also from the OS prompt (the options are lowercase and can not have a space after them) 6. verify the file is OK (GUIDE OPEN.MO -O) from the OS 7. verify that your data is all there using the list of items from step 3. Edit the records. You can create a VOC entry to your backup copy to compare if things don't look right. There is a section in the Administering UniData document on File Corruption that explains all of the above. There is also an Advanced File Fixing for UniData document. I'm not sure if I got it from the website or the support disc that they send out. hth Colin Alfke Calgary, Canada -Original Message- From: Buffington, Wyatt We are running UniData 6.0.4 on an HP.UX 11 and the following error keeps appearing: 2:blk check error in U_catch_tuple for file 'OPEN.MO', key '082352500', number=1327 I have run following command: :!guide OPEN.MO -o OPEN.MO Basic statistics: File type... Dynamic Hashing File size [dat001].. 8129536 [over001]. 43686912 File modulo. 7937 File minimum modulo. 7937 File split factor... 60 File merge factor... 40 File hash type.. 1 File block size. 1024 File Integrity: Group 1327, block 1328, record number 3 = 082352500 offset occurs in wrong order 35587084 Group 1327, block 34753, record number 3 = 082352500 offset error 35587084 Group 1327, block 34753, record number 2 = 076754900 record length of 414 is wrong. Group 1327, block 34753, record number 3 = 082352500 record length of 1035 is wrong. Group 1327, block 34753 bytes used 1449 and bytes left 989 are inconsistent Free blocks in overflow file(s). 7982 Management advice: This file's integrity has been compromised, please repair it. Files processed:1 Errors encountered: 5 We need to fix this problem, but the manuals are pretty vague on what steps are required. Do I use 'guide' and 'fixfile' or do I use 'verify2', 'dumpgroup' and 'fixgroup'? Can anyone help me with this? Wyatt Buffington --- 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] Guaranteed unique sequential keys
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Merrall Sent: Friday, April 25, 2008 8:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Guaranteed unique sequential keys On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere [EMAIL PROTECTED] wrote: So... in the best traditions of using a pile-driver to crack a nut you could roll your own . Of the top of my head, a locking service would be a U2 subroutine listening on a particular network port that is started/stopped along with the DB. Your client routines would use the socket functions to connect. The nice thing is you get the duplicate connection handling for free. U2 socket listeners are not multi-threaded so the first client in gets the socket. As long as you hold it for 1 clock tick before closing and have the other clients on a time-out longer than 1 clock-tick, you should get your unique keys. There are other options and they all have been tested. A master service phantom responds to all initial requests with a port# to connect back on. The client reconnects from the master over to the client phantom on that port. You can have X client phantoms handling the actual processes. That provides multi-client service, but it provides it at the cost of reconnections. I utilize a file-based spooling architecture in conjunction with inet/Winetd sockets in MVWWW to avoid this reconnection scenario, but that does have performance limitations. I did mention this was over-kill right? 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. Although the code itself is pretty simple and, in my experience on Unidata, the U2 sockets routines work very well, I would spend some time benchmarking to make sure this kind of effort is worthwhile. Assuming you have some spare server capacity, if the phantoms are using a lock file on a frequent basis, the file will likely be in cache anyway. HTH but probably not. Adrian GlenB --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] UniVerse Triggers
Hello, We have received reports that UV triggers have shown some instability. Does anyone have anything to share on this? We have been using them for a couple of years with no issues but were hoping for more details from other users, if available. Thanks much, -Baker --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Guaranteed unique sequential keys
Has anyone considered submitting the transactions to said phantom, and have one process control the writes? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen B Sent: Friday, April 25, 2008 10:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Guaranteed unique sequential keys -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Merrall Sent: Friday, April 25, 2008 8:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Guaranteed unique sequential keys On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere [EMAIL PROTECTED] wrote: So... in the best traditions of using a pile-driver to crack a nut you could roll your own . Of the top of my head, a locking service would be a U2 subroutine listening on a particular network port that is started/stopped along with the DB. Your client routines would use the socket functions to connect. The nice thing is you get the duplicate connection handling for free. U2 socket listeners are not multi-threaded so the first client in gets the socket. As long as you hold it for 1 clock tick before closing and have the other clients on a time-out longer than 1 clock-tick, you should get your unique keys. There are other options and they all have been tested. A master service phantom responds to all initial requests with a port# to connect back on. The client reconnects from the master over to the client phantom on that port. You can have X client phantoms handling the actual processes. That provides multi-client service, but it provides it at the cost of reconnections. I utilize a file-based spooling architecture in conjunction with inet/Winetd sockets in MVWWW to avoid this reconnection scenario, but that does have performance limitations. I did mention this was over-kill right? 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. Although the code itself is pretty simple and, in my experience on Unidata, the U2 sockets routines work very well, I would spend some time benchmarking to make sure this kind of effort is worthwhile. Assuming you have some spare server capacity, if the phantoms are using a lock file on a frequent basis, the file will likely be in cache anyway. HTH but probably not. Adrian GlenB --- 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] [UV] HELP - CORRUPT FILE???
Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] CASE CLOSED: [UV] HELP - CORRUPT FILE???
LIST.INDEX FILENAME STATS found the corrupted index. Have a great weekend. -- Forwarded Message: -- From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org (u2-Users) Subject: [UV] HELP - CORRUPT FILE??? Date: Fri, 25 Apr 2008 16:03:04 + Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] HELP - CORRUPT FILE???
Is this a distributed file? On Fri, Apr 25, 2008 at 10:03 AM, [EMAIL PROTECTED] wrote: Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- -Kevin http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] HELP - CORRUPT FILE???
Check the file permissions. If it's a directory type file also check the Parent directory permissions. Thanks, David A. Green www.dagconsulting.com (480) 813-1725 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 25, 2008 9:03 AM To: u2-Users Subject: [U2] [UV] HELP - CORRUPT FILE??? Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- 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] [UV] HELP - CORRUPT FILE???
Size of file. Are you close to the maximum file size for your OS? Free space available on volume. Maybe you just don't have any free space left to allocate. Record keys. Do they contain any system delimiters? On Fri, Apr 25, 2008 at 12:03 PM, [EMAIL PROTECTED] wrote: Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- 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] [UV] HELP - CORRUPT FILE???
What's the actual error message? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 25, 2008 11:03 AM To: u2-Users Subject: [U2] [UV] HELP - CORRUPT FILE??? Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Looking for ALIS
I just had a call from an Anzio (our product) user, new to her job, who is trying to find out if there is support for her freight forwarding app, called ALIS. Anyone have any info? Regards, Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: [EMAIL PROTECTED] company e-mail: [EMAIL PROTECTED] voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Guaranteed unique sequential keys
I believe we use a large pseudo random number as the key and put the time/date stamp in a log file. Your keys won't have the information in them about the sequence (although some may find that a better solution - let's not go there); however, a simply join/translate will get that for you. You can even do this across files hth Colin Alfke Calgary, Canada -Original Message- From: Glen B -Original Message- From: Adrian Merrall On Fri, Apr 25, 2008 at 10:19 PM, Marco Manyevere wrote: So... in the best traditions of using a pile-driver to crack a nut you could roll your own . Of the top of my head, a locking service would be a U2 subroutine listening on a particular network port that is started/stopped along with the DB. Your client routines would use the socket functions to connect. The nice thing is you get the duplicate connection handling for free. U2 socket listeners are not multi-threaded so the first client in gets the socket. As long as you hold it for 1 clock tick before closing and have the other clients on a time-out longer than 1 clock-tick, you should get your unique keys. There are other options and they all have been tested. A master service phantom responds to all initial requests with a port# to connect back on. The client reconnects from the master over to the client phantom on that port. You can have X client phantoms handling the actual processes. That provides multi-client service, but it provides it at the cost of reconnections. I utilize a file-based spooling architecture in conjunction with inet/Winetd sockets in MVWWW to avoid this reconnection scenario, but that does have performance limitations. I did mention this was over-kill right? 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. Although the code itself is pretty simple and, in my experience on Unidata, the U2 sockets routines work very well, I would spend some time benchmarking to make sure this kind of effort is worthwhile. Assuming you have some spare server capacity, if the phantoms are using a lock file on a frequent basis, the file will likely be in cache anyway. HTH but probably not. Adrian GlenB --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] HELP - CORRUPT FILE???
I'd check permissions, look to see if the file system is full (bytes inodes). From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Subject: [U2] [UV] HELP - CORRUPT FILE??? Date: Fri, 25 Apr 2008 16:03:04 + Hi all, HPUX 11, UV10.1.8 (PICK) I have users that are getting blown out of our system when trying to create new records in a file. From the address given in the error message from Universe, I see that it is a WRITE to a file. fixtool reported no errors COUNT FILE F1 DET-SUPP returns with no prob FILE.STAT FILE returns with no prob The file does have indexes so I tried /dbms/uv/uv/bin/blook -V on every index and that returns without issue Does anyone know of anything else I can look at? Thanks --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ Make i'm yours. Create a custom banner to support your cause. http://im.live.com/Messenger/IM/Contribute/Default.aspx?source=TXT_TAGHM_MSN_ Make_IM_Yours --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2][UV] User/Port history
Hello all! Is there anywhere in uniVerse that keeps a history of which users have been logged in on which ports? Basically, I'm looking for something equivalent to the old ACC file in the Pick world. I'm trying to track down some software/licensing issues, and to do so I need to know who the last person was that was on a particular port. Note that I'm talking UV ports here, not unix ports. Any help would be appreciated - even if it's someone telling me no such thing exists so that I stop looking. Thanks! Brian F. Paige Serta International [EMAIL PROTECTED] Direct line: 847-747-0451 Internal extension: 2051 Fax: 847-747-0551 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Guaranteed unique sequential keys
Marco, Have all the phantoms use a function or subroutine to get the next id based on the current system milliseconds. Use a semaphore lock to keep it singleton. Add a NAP statement so the next time it's run you're sure to get a different millisecond count -- note that many systems won't give 1ms granularity (IIRC Windows is about 6ms): FUNCTION GET.NEXT.ID * EQU MY$SEMAPHORE TO 55 EQU TD$TICKS LIT '(SYSTEM(99):((SYSTEM(12) * 1000) R%3))' * LOCK MY$SEMAPHORE MY.ID = TD$TICKS NAP 15 ;* must be big enough to get unique id's UNLOCK MY$SEMAPHORE RETURN (MY.ID) END rex Marco Manyevere wrote: What is the most reliable way to generate unique sequential keys without having to resort to a record on disk updated through readu/write? 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. I'm currently approximating this using a concatenation of date and time with millisecondsB but I'm worried about the possibility of two phantoms generating exactly the same key. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Indexes have disappeared
I just found out that the original indexes had a virtual path (correct terminology?) (../directory.name), which didn't work with the new version of UniVerse (10.2.7), so our vendor changed them to a physical path (u2/ directory.name), which didn't match our other system. So now we do a SET.INDEX every day after the copy from computer A to computer B. Fun. -- Louie in Seattle http://directory.name --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Indexes have disappeared
What was your old revision? If this was changed then it was changed for the worst. Jerry Banker Senior Programmer Analyst IBM Certified Solutions Expert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Louie Bergsagel Sent: Friday, April 25, 2008 4:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Indexes have disappeared I just found out that the original indexes had a virtual path (correct terminology?) (../directory.name), which didn't work with the new version of UniVerse (10.2.7), so our vendor changed them to a physical path (u2/ directory.name), which didn't match our other system. So now we do a SET.INDEX every day after the copy from computer A to computer B. Fun. -- Louie in Seattle http://directory.name --- 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] Problem Logging in to Universe/RHEL 5.1 Desktop
I have just installed RHEL 5.1 Desktop and Universe PE 10.2.7 on it. I have established a telnet connection to Universe, from both the server using the RHEL telnet client and from another client at 10.0.0.4 on the network using Accuterm. I get the same results from each of these telnet clients. When I completed the install of Universe, I ended up logged on to the uv account (WHO = uv from root) so I know that Universe was running at that time. When I first connect with the telnet client, I get the following login prompt, so I believe that Universe is running now: Red Hat Enterprise Linux Client release 5.1 (Tikanga) Kernel 2.6.18-53.el5xen on an i686 login: uv Password: Last login: Fri Apr 25 15:43:57 from 10.0.0.4 [EMAIL PROTECTED] ~]$ After I login using the Linux User and Universe account name uv and the Linux password for the uv account, I get the Last Login msg and the [EMAIL PROTECTED] ~]$ prompt. If I enter login at this prompt, I get: [EMAIL PROTECTED] ~]$ login login: If I then enter uv and its Linux user password again, I get: login: uv Password: Session setup problem, abort. [EMAIL PROTECTED] ~]$ I have checked the IBM Knowledge base and found nothing related to these symptoms. I don't know what to do at this point. Any suggestions will be greatly appreciated. tia, Dave Dave Taylor Sysmark Information Systems, Inc. Authorized IBM Business Partner 49 Aspen Way Rolling Hills Estates, CA 90274 (O) 800-SYSMARK (800-797-6275) (F) 310-377-3550 (C) 310-561-5200 www.sysmarkinfo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Problem Logging in to Universe/RHEL 5.1 Desktop
Dave - Befor you installed UniVerse did you create users that had a .bash_profile that put them in the UniVerse account directory and executed the uv command. After you log into any unix system, you need to cd to the directory that contains the account you want to run UniVerse in. Then execute the command uv at the unix prompt and you will be in UniVerse. Ken At 05:15 PM 4/25/2008, you wrote: I have just installed RHEL 5.1 Desktop and Universe PE 10.2.7 on it. I have established a telnet connection to Universe, from both the server using the RHEL telnet client and from another client at 10.0.0.4 on the network using Accuterm. I get the same results from each of these telnet clients. When I completed the install of Universe, I ended up logged on to the uv account (WHO = uv from root) so I know that Universe was running at that time. When I first connect with the telnet client, I get the following login prompt, so I believe that Universe is running now: Red Hat Enterprise Linux Client release 5.1 (Tikanga) Kernel 2.6.18-53.el5xen on an i686 login: uv Password: Last login: Fri Apr 25 15:43:57 from 10.0.0.4 [EMAIL PROTECTED] ~]$ After I login using the Linux User and Universe account name uv and the Linux password for the uv account, I get the Last Login msg and the [EMAIL PROTECTED] ~]$ prompt. If I enter login at this prompt, I get: [EMAIL PROTECTED] ~]$ login login: If I then enter uv and its Linux user password again, I get: login: uv Password: Session setup problem, abort. [EMAIL PROTECTED] ~]$ I have checked the IBM Knowledge base and found nothing related to these symptoms. I don't know what to do at this point. Any suggestions will be greatly appreciated. tia, Dave Dave Taylor Sysmark Information Systems, Inc. Authorized IBM Business Partner 49 Aspen Way Rolling Hills Estates, CA 90274 (O) 800-SYSMARK (800-797-6275) (F) 310-377-3550 (C) 310-561-5200 www.sysmarkinfo.com --- 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 Triggers
We started using triggers some months ago and so far no problems at all... I'm interested in what kind of instability issues you came across. Please let me know. ( We are a 370-Micro$oft Windows shop!) Horacio Pellegrino -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: Friday, April 25, 2008 8:02 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniVerse Triggers Hello, We have received reports that UV triggers have shown some instability. Does anyone have anything to share on this? We have been using them for a couple of years with no issues but were hoping for more details from other users, if available. Thanks much, -Baker --- 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/
