RE: [U2] UV: LIST.READU question
Im not sure about the strings / list_readu. I would imagine that strings just filters our readable characters from the list_readu file itself not the output of list_readu (unless you are piping the output). I used to use strings on large (non text) error logs and grep for certain data. Sorry, but thats all I can offer on that one. What you have to try to do is to pinpoint the two process involved and fix the locking strategy. All programs should lock files in the same 'direction' and in the same 'order' For example if you are updating lines on an order I think it is good to lock the order header first (even if you are not updating the order header). So once you have the order, nobody else can touch the order or the line items, because thats the rules. If you dont do this, then one process could be updating the lines and then head for the order header to update say a status field while another process is updating the header and heading for the lines and then you have a nice little deadlock. This is probably a whole 'nother topic. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hennessey, Mark F. Sent: Monday, December 19, 2005 3:16 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UV: LIST.READU question Anthony: We see that from time to time. However, only when we issue LIST.READU EVERY. It is a deadlock. Yes, as was pointed out by another poster as well (BobW), we were running with the EVERY option. And thanks for telling me how the entry got there. Using the unix 'strings' command, I see that list_readu will also output about Active Read Waiters. Another undocumented output... Would these be read deadlocks? Mark --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV: LIST.READU question
Anthony: We see that from time to time. However, only when we issue LIST.READU EVERY. It is a deadlock. Yes, as was pointed out by another poster as well (BobW), we were running with the EVERY option. And thanks for telling me how the entry got there. Using the unix 'strings' command, I see that list_readu will also output about Active Read Waiters. Another undocumented output... Would these be read deadlocks? Mark --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV: LIST.READU question
We see that from time to time. However, only when we issue LIST.READU EVERY. It is a deadlock. You have to find out who the two users are. In your example, it looks like a phantom or batch process and a user on a terminal. You have to pick one of the two to kill in order to free up the lock. We usually LOGTO UV. Go into deadlock administration and take care of the situation that way. Anthony > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Hennessey, Mark F. > Sent: Monday, December 19, 2005 12:31 PM > To: u2-users@listserver.u2ug.org > Subject: [U2] UV: LIST.READU question > > > We've come across some output from LIST.READU that appears to > not be documented. After the usual (and documented :) Group > and record locks, we saw: > > 0037: Active File Waiters: Owner Waiter > 0038: Device Inode Userno Userno > 0039:22595385493 44841 13 > > So, it appears to me that user 13 was waiting for user 44841 > to get done with whatever file has inode 493. > > Has anyone seen this before, and have an idea of what > qualifies a "Active File Waiter" to be captured by LIST.READU? > > We're running UV 10.0.8 on Solaris 8, by the way. > > Mark Hennessey > State of Connecticut > DSS/MIS Child Support Systems > Voice: 860-424-5261 > Fax: 860-424-4956 > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV: LIST.READU question
We look for this all the time. Usually, though, it only shows up if we use the command "LIST.READU EVERY". This is how we tell if someone is sitting in and Entry/Update screen instead of the Inquiry screen. We then go smack the fingers of the "Owner" ID with a ruler. (I like that part!) BobW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hennessey, Mark F. Sent: Monday, December 19, 2005 9:31 AM To: u2-users@listserver.u2ug.org Subject: [U2] UV: LIST.READU question We've come across some output from LIST.READU that appears to not be documented. After the usual (and documented :) Group and record locks, we saw: 0037: Active File Waiters: Owner Waiter 0038: Device Inode Userno Userno 0039:22595385493 44841 13 So, it appears to me that user 13 was waiting for user 44841 to get done with whatever file has inode 493. Has anyone seen this before, and have an idea of what qualifies a "Active File Waiter" to be captured by LIST.READU? We're running UV 10.0.8 on Solaris 8, by the way. Mark Hennessey State of Connecticut DSS/MIS Child Support Systems Voice: 860-424-5261 Fax: 860-424-4956 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
