Here's some troubleshooting tips we use for our applications using the U2 APIs
in background non-interactive processes.
We have a common interfacing subroutine our API clients must use to sign-on
and initialise their UV environment. In that code, we turn on COMO output, to
capture any output
If it is a session hang you're possibly looking at locking issues so check
the lock table to see what is waiting and also check for any group locks
that persist.
If it is UniVerse, It's also a good idea to check the errlog file in the uv
account: if that does not exist, create it as a zero length
I will chime in since I work with Ravi and I am dealing with this issue
along with him.
Thanks for the response Brian, PORT.STATUS should be useful for our
situation.
I'll try and be a little more specific and hopefully I know what I'm
talking about: We have a web application which is using
Andy:
The first place I'd look for any UO errors is the UO error log. In UD,
you need to create a serverdebug item in the @UDTHOME directory (in my
case this is in E:\U2\ud). The contents of this item is:
udcs 10 E:\U2\ud\log\udcs\udcs.log
...which indicates maximum logging and the log
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
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 u...@edclark.net
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon, Jan 7, 2013 2:43 pm
Subject: Re: [U2] How to check
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
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 PA
2
