|
Hello Jim, Sunday, October 15, 2000, 3:45:52 PM, you wrote: > Just to add 2 more cents to the discussion, in 17 words or less, a single > pgm read/writing 400 times is absolutely not equal 400 users read/writing 1 > time. So the question remains, how to be absolutely sure of no duplicate, > yet fast to assign. Last time I did this, it was a combination key from RPG > pgm data structure JOB, JOB NBR, and then timestamp (a single user could not > enter 2 records within the same timestamp). (if you want file keyed in entry > order, just move timestamp to 1st key field). This requires no reading any > disk before writing. Not sure if Job, Job Nbr unique enough in a CGI > application, but I bet something in that data structure is. BTW- this has > been most interesting & made me think of some past high-volume pgms. jim Well Jim I agree that the likelihood of a user job writing twice in one timestamp click is impossible at this moment, perhaps they will be able to in the future. Also the applications that I have had to do this for were basic order entry style systems so they sort of wanted a unique order number (and the timestamp thingy would not have been acceptable for them [it is a conceptual thing]) Besides keying in that thing would be pretty nasty :-) As far as the 400 invocations being different from 400 simultaneous invocations, well since the AS/400 only allows one job to lock a data area at any point in time that pretty much serializes the process no matter how many jobs try to do it at once. As was pointed out this is both a blessing and a curse. +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.