> D3 has a 'System-Wide' Unique ID generator in their SYSTEM() selectiosn... > U2 does not. Darn it.
Ah, but nothing's free. To ensure uniqueness, there needs to be some sort of negotiation. Years ago I worked on a Sequoia system running Pick O/A. We were happy to see SYSTEM(19), which provided a unique ID. We used it in some processes that were used by many users and discovered that performance suffered dramatically. After talking with the system engineers, we discovered that there was a semaphore that negotiated the requests to ensure that exactly one user was served at a time, then assigned the unique ID to that user. The problem was that, if you have dozens of users requesting an ID simultaneously, you have a bottleneck. Because we didn't care what the ID contained, we did something similar to what others here have suggested - a combination of port, date and time the program started, and a counter unique to the process. Performance system-wide improved dramatically and immediately. If it's important to have an ID that guarantees that you can sort the file in the order the transactions occurred, the READU scenario is probably the best. You could probably work out something with linked C routines and/or a socket server, but there will still be a bottleneck if there are many simultaneous requests. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
