I'm reading through all these responses and probably won't respond to each individually. But I do thank you all for your input.
There are several suggestions like the one below that involve incrementing the control record BEFORE the transaction starts. Either grab a block, or grab a master number and start incrementing sub-numbers as needed. Maybe go back & fix the control record after transaction is ROLLBACKed or otherwise doesn't go as expected. I like the '*':SUB.KEY idea below. Ken Wallis had a similar method. This approach of claiming the sequential-id key (or block of keys) before the transaction starts assumes one has a fair idea of what will be needed before TRANSACTION START is executed. But one may not know that until deep into processing. Or - even better! - maybe your code is modular enough that these kinds of updates are going to happen inside blackbox external utility subroutines, where the outer process does not know or care about the kind of updates that might happen inside those calls. -----Original Message----- From: Bob Woodward > But his comments have generated a modification idea to my earlier suggestion. > If, before the TRANSACTION START command, you get a "next available ID" then > use that as a "root" value, you can then create a sequential number with an > internal sequential number. IE: > >ROOT.KEY='' >LOOP UNTIL ROOT.KEY > RELEASE ;* make sure all locks are released > READU ROOT.KEY FROM CF, "NEXT.ROOT.KEY" THEN > READ JUNK FROM OUTFILE, ROOT.KEY:"*1" THEN > WRITE ROOT.KEY+1 ON CF, "NEXT.ROOT.KEY" > ROOT.KEY='' > END > END >REPEAT >WRITE ROOT.KEY+1 ON CF, "NEXT.ROOT.KEY" >TRANSACTION START > SUB.KEY = 1 > EXIT.FLAG='' > LOOP > OUTRCD = '' > [do whatever builds OUTRCD] > WRITE OUTRCD ON OUTFILE, ROOT.KEY:"*":SUB.KEY > SUB.KEY += 1 > [whatever to determine if time to exit] > UNTIL EXIT.FLAG REPEAT >TRANSACTION COMMIT ;* or whatever logic to rollback. > > >This is actually a modification of another suggestion to lock a "block" of numbers, too. Difference is a block of numbers would be a maximum number of records that >could be created, like 123400 to 123499 if blocking to a factor of 100. With a multi-part >key, using the asterisk, you no longer have the maximum number block. It could go 10, 100, or> even 10,000 if need be. You could even use something like ROOT.KEY:"*0" if you like as a sort of "header" record to keep track of how many records there should be for the ROOT.KEY family. This should keep the auditors happy, "Transactions" sequential, and cross-transaction locking to an extremely short interval. Also, by using READU without the LOCKED clause, the program will wait that short interval until the record is available. As a side comment, this method will also make it easy to keep records in a sorted, associated order. You could even get a count of process runs by selecting @ID = "[*1" or SUB.KEY = "0" if you set the dict record. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
