Resolution:
No one responded to this on-list. I assume no one else had seen
LIST.REDU do this, either.
I raised it with my support, Strategy 7, who asked IBM.
They say it is benign.
The explanation was a little vague, but I gather that it is a timing
issue.
If the lock table is changing while LIST.READU is reading it to build
its report, it might come up with device=0,inode=0 as the data
disappears.
Sort of a blurry snapshot of a moving target.
In fact, I have been monitoring a runaway process that holds dozens or
hundreds of locks then releases them all together. I think that is when
I see this. That would be consistent with the blurry photo theory.
I have not had any negative fallout from this, but since I had never
seen it before, I didn't know if it was harbinger portending
maleficence.
For what it's worth,
Charles Stevenson
From: Stevenson, Charles
Sent: Friday, January 27, 2006 12:28 PM
What does device 0 Inode 0 mean?Notice the last line:
LIST.READU USER 137 EVERY
Active Group Locks:Record
Group Group Group
Device Inode Netnode Userno Lmode G-Address.
Locks ...RD ...SH ...EX
1075970056 244260137 109 IN 27800 1
0 0 0
1075970056 80410137 241 IN 4C40B800 1
0 0 0
Active Record Locks:
Device Inode Netnode Userno LmodePid Login Id
Item-ID.
1075970056 244260137 109 RU 1441 mholl
3001980
1075970056 80410137 241 RU 1441 mholl
3001980
0 00137 341 RU 1441 mholl
584343
Is this perhaps something that disappeared in the middle of
list.readu's attempt to examine it?
It seems like I have been seeing a rash of these lately.
UV 10.0.16, HPUX 11i.
Thanks,
Chuck Stevenson
---
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/
