RE: UV write fatal error
Hmmm. It's a very curious situation. Your data doesn't appear to be anything out of the ordinary (though it's neat about your munging). Have you tried using the blook utility to scan through the btree file to see if anything is out of the ordinary? From the OS level, just issue blook without any parameters to get its syntax and options: Usage: blook [options] file +a address display nodes from addr to end -a address display node at addr -d display record keys and data -k display record keys -i keylist display item "key" only -n disable auto pagination -r traverse descending (default ascending) -s generate statistics -v verify file integrity: no details -V verify file integrity: detailed report Environment variable interaction: LINES to control display depth COLS to control display width You might want to direct the output to a file then peruse it with your fav editor. I wrote this utility when I was implementing the secondary index files. Maybe you might be able to figure out what the heck is causing your troubles, pay close attention to see if maybe your inserted data might fall at the boundary of a node and a split is aborting. Let me know if you need any help in making heads or tails of anything. At 03:39 PM 02/18/2004, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Wednesday, February 18, 2004 12:06 PM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error So what exactly is the particular data item that is causing the grief? >Trim I am storing IP address information. My record ID is of the form 323208*3232223231. This ID is two numeric values that represent the IP address as a sequential integer (first octet multiplied by 2^24, second multiplied by 2^16, etc. then summed, then left-filled with zeros to a width of 10). The second numeric is the same if it is a single address. If it is a range of addresses, the first value is the beginning of the range and the second the end of the range. I convert the address being stored into the above form and do the BSCAN in descending order on the IP file looking for a match or an adjacent record (determined by additional code) that overlaps the record being stored. This process has worked flawlessly for all but a handful of records being stored, including the example above (323208*3232223231, which is 192.167.204-207, by the way). An example of the data this record structure would contain is as follows: 323208*3232223231 1> 1*69171 2> 192.167.204.0 3> 192.167.207.255 4> 192.167.204-207 I work for a publishing company and the IP addresses belong to our customers for our web-accessed databases. Thanks in advance for your consideration. Jimi -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Wednesday, February 18, 2004 12:06 PM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error So what exactly is the particular data item that is causing the grief? >Trim I am storing IP address information. My record ID is of the form 323208*3232223231. This ID is two numeric values that represent the IP address as a sequential integer (first octet multiplied by 2^24, second multiplied by 2^16, etc. then summed, then left-filled with zeros to a width of 10). The second numeric is the same if it is a single address. If it is a range of addresses, the first value is the beginning of the range and the second the end of the range. I convert the address being stored into the above form and do the BSCAN in descending order on the IP file looking for a match or an adjacent record (determined by additional code) that overlaps the record being stored. This process has worked flawlessly for all but a handful of records being stored, including the example above (323208*3232223231, which is 192.167.204-207, by the way). An example of the data this record structure would contain is as follows: 323208*3232223231 1> 1*69171 2> 192.167.204.0 3> 192.167.207.255 4> 192.167.204-207 I work for a publishing company and the IP addresses belong to our customers for our web-accessed databases. Thanks in advance for your consideration. Jimi -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
So what exactly is the particular data item that is causing the grief? At 02:50 PM 02/18/2004, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Ok. So there WAS a bscan done on the T25 file prior to attempting the write. Since this is done from within BASIC, my guess is that the active scan is causing some type of error. Try this; after the scan has verified that the data item does NOT exist, close and reopen the data file, THEN attempt your write (yes I know that this may invalidate the notion that the record does not exist). This would test to see if the active scan of the T25 file is interfering with the low level write, as the close of the data file would automatically terminate the scan (there is no other way from within BASIC). I wrote the code for bscan back in 1992 so I don't recall all different interactions involved, but it could be a long-standing bug that never appeared or not reported. In any case, if you could try that, I'd be interested in the results. Trim I closed and reopened the file after the BSCAN and before the WRITE with the same result. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Ok. So there WAS a bscan done on the T25 file prior to attempting the write. Since this is done from within BASIC, my guess is that the active scan is causing some type of error. Try this; after the scan has verified that the data item does NOT exist, close and reopen the data file, THEN attempt your write (yes I know that this may invalidate the notion that the record does not exist). This would test to see if the active scan of the T25 file is interfering with the low level write, as the close of the data file would automatically terminate the scan (there is no other way from within BASIC). I wrote the code for bscan back in 1992 so I don't recall all different interactions involved, but it could be a long-standing bug that never appeared or not reported. In any case, if you could try that, I'd be interested in the results. Trim I closed and reopened the file after the BSCAN and before the WRITE with the same result. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
Jimi, I recall I had write errors about 2 years ago related to indexes, which just happen to be type-25 files. Maybe you're seeing the same bug. It sounds similar. Check this list's archives for April 2002, subject may be "UV Missing items in an index - uv 9.6.2.1." I believe my coworkers saw the same problem at 9.5, before my time here. I had to turn off indexing and I think IBM had a useful fix in maybe 9.6.2.6. I think there was mention of it in UV upgrade patchlist, too. Mr. Herbert gave me a hand with this back then, too. Contact me off-list and maybe I can dig up the details from somewhere other than my brain from which said details seem to have been purged. - Chas. Stevenson > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert > Sent: Tuesday, February 17, 2004 10:32 AM > To: U2 Users Discussion List > Subject: RE: UV write fatal error > > > Ok. So there WAS a bscan done on the T25 file prior to attempting the > write. Since this is done from within BASIC, my guess is that the active > scan is causing some type of error. Try this; after the scan has verified > that the data item does NOT exist, close and reopen the data file, THEN -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
Ok. So there WAS a bscan done on the T25 file prior to attempting the write. Since this is done from within BASIC, my guess is that the active scan is causing some type of error. Try this; after the scan has verified that the data item does NOT exist, close and reopen the data file, THEN attempt your write (yes I know that this may invalidate the notion that the record does not exist). This would test to see if the active scan of the T25 file is interfering with the low level write, as the close of the data file would automatically terminate the scan (there is no other way from within BASIC). I wrote the code for bscan back in 1992 so I don't recall all different interactions involved, but it could be a long-standing bug that never appeared or not reported. In any case, if you could try that, I'd be interested in the results. At 12:11 PM 02/17/2004, you wrote: No, the value does not get written to the type 25 file. The data is not pre-existing. The BSCAN is done to verify this fact before attempting the write. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Does the data value actually get inserted into the type 25 file if you check after the write fails? Also, is the data pre-existing within the type 25 file and this is an update to that record? Sounds almost like a memory allocation or rotating file pool problem. The on error branch (actually ANY branch) would only be followed if the run-machine wasn't crashing underneath you, which, if you are being dropped back to the command prompt, is happening. At 11:33 AM 02/17/2004, you wrote: > > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On Behalf Of Ray Wurlod >Sent: Friday, February 13, 2004 12:13 PM >To: [EMAIL PROTECTED] >Subject: RE: UV write fatal error > >Permissions? All the preceding steps (Open, BSCAN) can be done without >write permission. Write, needless to add, cannot. > > > >-Original Message- > > >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > > > > > >I am attempting to write a record to a type 25 file and apparently > > >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on > > >W2K > > > >SP4. I have constructed the WRITE statement to include all possible > > >(I > > >think) branching, yet the program goes to the command prompt when > > >the > > > >WRITE is executed without following any of the branches. The WRITE > > >statement is as follows: > > > > > [SNIP] > >I have no problem writing other values. It is only this particular data >value that seems to produce the error. Why wouldn't the program follow >the on error branch? >-- >u2-users mailing list >[EMAIL PROTECTED] >http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
No, the value does not get written to the type 25 file. The data is not pre-existing. The BSCAN is done to verify this fact before attempting the write. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Tuesday, February 17, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Does the data value actually get inserted into the type 25 file if you check after the write fails? Also, is the data pre-existing within the type 25 file and this is an update to that record? Sounds almost like a memory allocation or rotating file pool problem. The on error branch (actually ANY branch) would only be followed if the run-machine wasn't crashing underneath you, which, if you are being dropped back to the command prompt, is happening. At 11:33 AM 02/17/2004, you wrote: > > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On Behalf Of Ray Wurlod >Sent: Friday, February 13, 2004 12:13 PM >To: [EMAIL PROTECTED] >Subject: RE: UV write fatal error > >Permissions? All the preceding steps (Open, BSCAN) can be done without >write permission. Write, needless to add, cannot. > > > >-Original Message- > > >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > > > > > >I am attempting to write a record to a type 25 file and apparently > > >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on > > >W2K > > > >SP4. I have constructed the WRITE statement to include all possible > > >(I > > >think) branching, yet the program goes to the command prompt when > > >the > > > >WRITE is executed without following any of the branches. The WRITE > > >statement is as follows: > > > > > [SNIP] > >I have no problem writing other values. It is only this particular data >value that seems to produce the error. Why wouldn't the program follow >the on error branch? >-- >u2-users mailing list >[EMAIL PROTECTED] >http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
Does the data value actually get inserted into the type 25 file if you check after the write fails? Also, is the data pre-existing within the type 25 file and this is an update to that record? Sounds almost like a memory allocation or rotating file pool problem. The on error branch (actually ANY branch) would only be followed if the run-machine wasn't crashing underneath you, which, if you are being dropped back to the command prompt, is happening. At 11:33 AM 02/17/2004, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Friday, February 13, 2004 12:13 PM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Permissions? All the preceding steps (Open, BSCAN) can be done without write permission. Write, needless to add, cannot. > >-Original Message- > >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > > > >I am attempting to write a record to a type 25 file and apparently > >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on W2K > >SP4. I have constructed the WRITE statement to include all possible > >(I > >think) branching, yet the program goes to the command prompt when the > >WRITE is executed without following any of the branches. The WRITE > >statement is as follows: > > > [SNIP] I have no problem writing other values. It is only this particular data value that seems to produce the error. Why wouldn't the program follow the on error branch? -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Friday, February 13, 2004 12:13 PM To: [EMAIL PROTECTED] Subject: RE: UV write fatal error Permissions? All the preceding steps (Open, BSCAN) can be done without write permission. Write, needless to add, cannot. > >-Original Message- > >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > > > >I am attempting to write a record to a type 25 file and apparently > >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on W2K > >SP4. I have constructed the WRITE statement to include all possible > >(I > >think) branching, yet the program goes to the command prompt when the > >WRITE is executed without following any of the branches. The WRITE > >statement is as follows: > > > [SNIP] I have no problem writing other values. It is only this particular data value that seems to produce the error. Why wouldn't the program follow the on error branch? -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
Permissions? All the preceding steps (Open, BSCAN) can be done without write permission. Write, needless to add, cannot. > >-Original Message- > >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > > > >I am attempting to write a record to a type 25 file and apparently > >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on W2K > >SP4. I have constructed the WRITE statement to include all possible (I > >think) branching, yet the program goes to the command prompt when the > >WRITE is executed without following any of the branches. The WRITE > >statement is as follows: > > > [SNIP] -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
Can you edit/save an item with this ID from TCL? Do you have a trigger on the file that may be failing the write? Sorry, not much help -- Colin Alfke Calgary, Alberta Canada When I tried before, I could not save the record from TCL. I can now, which leads me to believe that previously the group lock was still in effect. No triggers exist. Thanks. Jimi DeRouen -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: UV write fatal error
>-Original Message- >From: Jimi DeRouen [mailto:[EMAIL PROTECTED] > >I am attempting to write a record to a type 25 file and apparently >getting a fatal error. The platform is UV 9.5.1.1b Pick flavor on W2K >SP4. I have constructed the WRITE statement to include all possible (I >think) branching, yet the program goes to the command prompt when the >WRITE is executed without following any of the branches. The WRITE >statement is as follows: > [SNIP] > >I am stepping through the program in the debugger, and have verified >that the file IP is open, the record id IPADDRESSID is valid, >the record >data IP.REC is valid, and the record does not already exist in the >destination file. The program has done a BSCAN on the destination file >prior to the write to verify the record does not already exist or >conflict with the record to be written. This BSCAN has completed >successfully, leaving a group lock. The WRITE statement then >dumps me to >the TCL prompt without taking any of the above branches. It >almost seems >to me to be an OS level write error somehow not being trapped by >Universe. It only occurs on this particular data value which >leads me to >believe that it is failing on a particular disk location. > >I gratefully await the group's wisdom. > >Jimi DeRouen Can you edit/save an item with this ID from TCL? Do you have a trigger on the file that may be failing the write? Sorry, not much help -- Colin Alfke Calgary, Alberta Canada "Just because something isn't broken doesn't mean that you can't fix it" Stu Pickles -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
