[Top] [All Lists]

Re: [nv-l] Dynamic Workspace

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Dynamic Workspace
From: James Shanks <jshanks@us.ibm.com>
Date: Tue, 31 Jan 2006 10:26:56 -0500
Delivery-date: Tue, 31 Jan 2006 15:27:36 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <1A5AB46AA116114FB0EF78BBE5AA14A10219B281@CP2K3TLCEMLV1.capitol.local>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
That's a lot of issues in one posting, Catalina.  I'm not sure anyone can
address them all.

But "File --> Save As" from nvevents creates a textual report of the events
shown in your workspace.  To save your environment your must pull down
"Options --> Save Environment"  This creates the NvEnvironment subdirectory
in the operator's $HOME directory with the Workspaces file in it.    To get
this file read automatically on start-up, you must edit the
/usr/OV/app-defaults/Nvevents and change the nvevents.loadEnvOnInit=True"
there or put it in the .Xdefaults file.  I prefer the former, because I am
never sure of the order of precedence.   If you make a change in the fly,
then you'll need to do
       xrdb -merge /usr/OV/app-defaults/Nvevents
 to make certain your changes are merged in.  Note that if you don't change
the app-defaults file and someone afterward does the merge, it will
overwrite your settings.

Are your operators in the habit of doing the   "Options --> Save
Environment"  thing themselves before they exit?  If they do, then that
will override the Workspaces file with whatever was current at the time.
So if you set them up to open three workspaces, and they close two, and
save the environment, then when they come up again they will only get the
one workspace.

The rest of what you are describing seems like a performance problem to me,
with event windows seeming to freeze and not populating.   The X  GUI is
very resource intensive and multiple events windows only exacerbate that.
So perhaps you are trying to have to many open at once.  I don't have a
good rule of thumb to give you.  There is one message in the log which may
speak to this, the first one:
      /usr/bin/netview[64] ulimit 0403-045
The specified value is outside the user's allowable range.

I'm not certain how the netview command got put into /usr/bin rather than
/usr/OV/bin, but it does try to set unlimited ulimits for things like
memory and stack size to prevent  resource shortages and the sort of freeze
you described, so perhaps you had better look into giving the user who had
the problem unlimited access to system resources.  I can't tell what one is
"outside the user's limit"  but the netview command is a script and you can
trace it.

The rest  of the messages in the log you posted are from the java
maptreeserver.  They have nothing to do with the nvevents GUI, except that
the java processes take resources that might be used to run it.  I can't
interpret what the messages mean -- you'd need to call Support about that.
They may also be able to get you some help in getting a performance review
of your machine to see whether you have the resources to do everything your
are trying to do at one time.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web