Thank you - I realized that there were lots of questions but I wasn't
sure if it was 1 big issue or multiple issues. I will call support for
help on the resource problem.
thanks again.
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of James Shanks
Sent: Tuesday, January 31, 2006 9:27 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Dynamic Workspace
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.
HTH,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|