Re: [UV] READ READU on a part file belonging to a Distributed file
At 09:32 PM 04/06/2004, you wrote: Under Universe if I attempt to read a record (using READ) from a part file but using a key which actually maps (via the partitioning algorithm) to a different part file - then the READ just takes the ELSE clause without setting STATUS() to anything. Because within the run machine, a plain old READ just simply tries to read the record id out of the file you passed in. The run machine Fread function, calls DBread, which then calls the low level DBfind routine, which will simply not locate the record in the group it should belong in and (internally) returns a 7 back up to the run machine Fread function. Unfortunately, the Fread code won't set STATUS for a 7 (looks like a coding deficiency). I'm assuming that universe code still looks fairly much the same here. Altering the program to use READU instead of READ and the ELSE clause is still taken - but this time STATUS() is set to 2. Knowing how READ works, READU believe it or not, works slightly differently. The Freadu function calls DBreadLock, which actually DOES check to see if you are working within a partfile. If you are, then it makes certain that the key you want actually should exist in the file. If it does, then dandy. If not, it (internally) returns a 37 back up to the Freadu code, which correctly sets the STATUS based on that. Looking in the Universe Basic manual I can't find mention of what a STATUS() value of 2 means in relation to a READU statement (although it does say -2 (negative 2) signifies the part number is invalid. I checked ED.B and COPY.B in the uv BP file, and both of these programs specifically check for a STATUS() value of 1 or 2 after doing a READU and then display an appropriate error message relating to part files and distributed files. 1 = bad partfile algorithm 2 = no part file / not in partfile 3 = unmappable record id (NLS only) 4 = unmappable record data (NLS only) What I can't understand is why the READ (without setting a lock) doesn't return the same STATUS(). How am I supposed to determine that the reason the record wasn't found was due to key being invalid and not just because it didn't exist? Now you know why. Hope this helps. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
[UV] READ READU on a part file belonging to a Distributed file
Under Universe if I attempt to read a record (using READ) from a part file but using a key which actually maps (via the partitioning algorithm) to a different part file - then the READ just takes the ELSE clause without setting STATUS() to anything. Altering the program to use READU instead of READ and the ELSE clause is still taken - but this time STATUS() is set to 2. Looking in the Universe Basic manual I can't find mention of what a STATUS() value of 2 means in relation to a READU statement (although it does say -2 (negative 2) signifies the part number is invalid. I checked ED.B and COPY.B in the uv BP file, and both of these programs specifically check for a STATUS() value of 1 or 2 after doing a READU and then display an appropriate error message relating to part files and distributed files. What I can't understand is why the READ (without setting a lock) doesn't return the same STATUS(). How am I supposed to determine that the reason the record wasn't found was due to key being invalid and not just because it didn't exist? If I remember correctly under PI/Open when attempting to READ (or READU) a record using an incorrect key, the program would take the ON ERROR clause with STATUS() being set to 32240. Another related problem were having at the moment - when attempting to read a VALID record from a part file via uvnet using READ - the record is read correctly BUT using READU the ELSE clause is taken and again STATUS() returns 2 even though the record does exist in the file. Any ideas on this one? Adrian Womack Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
