If you wanted a quick glance at a file with out running a program, And if
your careful and have root or admin access you can use filepeek.
The only thing you need is the first page, then 'q' to quit.
Default mode will tell you.
# /usr/uv/bin/filepeek VOC
filepeek status:
Active file ..
The subject of this email says that the job is in PA, but the linked page says
the job is actually in Orlando, FL.
Does anybody know which is correct?
Is it HD Supply?
Karen Bessel
Developer
P: 972.713.3770, ext. 113472
___
U2-Users mailing list
U2
Is there a way to resync, or clean the lock list? It seems like every
once in a while we will get garbage in the lock list that will not go
away until we reboot.The users are long since logged off and these
locks do not show up in uniadmin. It doesn't actually seem to do
anything other than m
Hi U2 Guru's
Can I tell when a sproc was last executed or who executed it. If so
how. Some way to get statistics and access logs. Reason we are asking
this is we are having a session hang issue we have tracked it down to a
session user but have no clue which sproc did the call to trouble shoot
Toad the wet sPROCet !!
A lot of procs get run from the VOC, but for performance reasons it's usually
suggested that the proc in the VOC be only a linkage that calls a proc from a
file. (would you eat it with a proc, would you eat it in a VOC, I do not like
green eggs and ham, I do not like the
Explain more this performance issue of which you speak.
How is a proc in a file different from the proc in the VOC?
-Original Message-
From: Ed Clark
To: U2 Users List
Sent: Mon, Jan 7, 2013 2:43 pm
Subject: Re: [U2] How to check which sproc is called by user
Toad the wet sPR
I've heard that a lumpy VOC is not recommended by the MV Doc.
It causes overflows and more disk IO. Not to mention the dreaded disk seek - oh
no!
If all you measured was your proc in the VOC, all would be good (on wood you
should knock).
But with a large proc in the VOC and your other entries in
I've heard that a lumpy VOC
is not recommended by the MV Doc.
It causes overflows and more disk IO.
Not to mention the dreaded disk seek - oh no!
If all you measured was your proc in the VOC,
all would be good (on wood you should knock).
But with a large proc in the VOC and your other entries
Or a security subroutine which performs an auditing function. This goes in
attribute 4 of a remote VOC pointer.
VOC File
StoredProcedurePointer
<1> R
<2> StoredProcedureFile
<3> StoredProcedureName
<4> SecurityRoutine
StoredProcedureFile
StoredProcedureName
<1>
Looks like UV? What version or platform? Did these user process normally exit
UV or did they drop connectivity or abnormally terminate from UV??
UV Lock Daemon typically cleans-up non-deadlock locking issues, including
orphaned locks (sometimes :)).
-Original Message-
From: u2-users-bo
10 matches
Mail list logo