Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Flakey EAS 3.5 Installation, HELP!

4 posts in General Discussion (old) Last posting was on 2000-02-24 20:38:50.0Z
Andrew Hart Posted on 2000-02-18 22:56:33.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 18 Feb 2000 16:56:33 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Flakey EAS 3.5 Installation, HELP!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 157
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38ADCE21.89FD6270@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28344
Article PK: 160374

I hardly know where to begin on this one...

We have a production server which has been giving us many problems over
the past few weeks. We originally installed 3.0 on this server, which is
locked away in a room and is being shared with another java based
application for digital asset management called Teams from Artesia
Technologies. ( http://www.artesiatech.com ). We have experienced a
series of inexplicable problems with our jaguar installation on this
machine: instability of the jaguar server, inability to view the
srv.log file, etc. I'll fast forward to the latest evolution of the
problem:

We uninstalled Jaguar completely. First we did an uninstall, then we
whacked all of the directories, and finally, we deleted all references
we could find in the registry. Then, we reinstalled EAS 3.5, Advanced
Deployment edition. First, we encountered problems in using JagManager
on that machine. We launch the JaguarManager, we click on connect, it
says in the status bar at the bottom of the window that we are
connected, but upon trying to expand that branch of the tree, nothing
happens. Remotely connecting with the new jaguar manager from another
workstation, we were able to connect and everything seemed to work
except that we couldn't view the srv.log file. It just comes up as
empty with a file size of -1, although it is in fact NOT empty. On
inspecting the log with a text editor we see error messages like:

Feb 11 14:36:06 2000: FileViewer::Initialize - Failed to open log file:
srv.log.
Feb 11 14:36:06 2000: FileViewerImpl::_openLog() -
intl_iocsfopen(srv.log, INTL_IO_READ) Failed.
No such file or directory.

We had originally encountered this problem under EAS 3.0. I posted a
message regarding several days ago. At that time, the problem just
magically went away and we were unable to determine why we had it in the
first place and what fixed it. We suspected some sort of conflicts
between the TEAMS software and Jaguar, since the last change to the
server that we were able to identify was a change in some of the TEAMS
services that were being launched. Now the problem is back, although,
additionally, we are now unable to view ANY server information via
JaguarManager run locally on the server itself.

This morning, we were connected via JaguarManager from a remote machine
and trying to set up some connection caches. During this process, the
jaguar service (jagsrv.exe) crashed. Now, we are unable to get it up
and running. I have an excerpt from the srv.log file:
---------------------------------------------------------------------------------------------------------------------------

Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'

Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'

Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
Feb 18 15:46:00 2000: Connection cache initialization failed
Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'

Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'

Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
Feb 18 15:46:00 2000: Connection cache initialization failed
Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'

Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'
---------------------------------------------------------------------------------------------------------------------------

Now, we don't know exactly what sqllib18.dll is, but we know that
ociwi2.dll is a typo and that it should be "ociw32.dll". We *think*
that this misconfiguration might be causing the server to crash, but we
don't know how to fix it without re-installing (for what would be about
the 20th time). We tried running the JagRepair utility, but
unfortunately, since we can't get JaguarManager to run we can't get in
there to fix this.

We have gone over our environment variables over and over and tried
changng things to no avail. Currently, we have the following
environment variables defined:

---------------------------------------------------------------------------------------------------------------------------

CLASSPATH = .;F:\EAS35\Shared\Sun\Jdk118\lib\classes.zip;F:\EAS35\Jaguar
CTS 3.5\html\classes;F:\EAS35\Jaguar CTS
3.5\java\classes;f:\EAS35\Shared\PowerBuilder\classes.zip

JAGUAR = F:\EAS35\Jaguar CTS 3.5

JAGUAR_CLIENT_ROOT = f:\EAS35\Jaguar CTS 3.5\client

JDK_LATEST = f:\EAS35\Shared\Sun\Jdk118

JRE_LATEST = F:\EAS35\Jaguar CTS 3.5\jre

PATH = F:\orant\bin;C:\WINNT\system32;C:\WINNT;C:\Program
Files\Mts;f:\alchemy;C:\ntreskit;f:\JavaSoft\bin;g:\TeamsSrv\bin;F:\EAS35\Jaguar
CTS 3.5\dll;F:\EAS35\Jaguar CTS
3.5\client\dll;f:\EAS35\Shared\Sun\JDK118\bin;f:\EAS35\Shared\PowerBuilder

User Variables....
JS_JAGUAR=localhost:9000
---------------------------------------------------------------------------------------------------------------------------

We're confused about the JRE_LATEST environment variable since the value
(above) doesn't seem to be a valid directory. I am assuming that this
is used only by the JaguarManager, not the Jaguar Server itself.

SUMMARY:

So, if anyone can give me some concise steps to troubleshoot this
problem, I would be very grateful. As I've said, we've tried changing
these environment variables, but nothing seems to work. We've copied
over the settings from an installation that DOES work, with no success.
We think there may be some conflicts with this other TEAMS java-based
software, but we can't see it and are not sure what to look for since
the CLASSPATH variable doesn't seem to contain anything pertinent to
that package and the latest round of problems is occurring even when
their software is not running. It doesn't help that the server is
locked up and we don't have full access to the machine on a regular
basis.

Thanks.


Keith Roscarel Posted on 2000-02-23 20:09:59.0Z
Newsgroups: sybase.public.easerver
From: "Keith Roscarel" <keithr@accint.com>
Subject: Re: Flakey EAS 3.5 Installation, HELP!
Date: Wed, 23 Feb 2000 15:09:59 -0500
Lines: 148
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
NNTP-Posting-Host: clients.accint.com 141.154.97.1
Message-ID: <347_TPr6Zpjf$GA.202@forums.sybase.com>
References: <347_38ADCE21.89FD6270@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28026
Article PK: 159925

We are trialing 3.5 and 3.0.1 on production servers.

With regards to the crash when setting up the connection caches, we also
came accross this in 3.5. The reason we had selected ODBC but had not
supplied 'odb32.dll' as the driver. On the next restart, Jaguar crashed. A
reinstall was our solution (and the supplying of the correct dll on the
cache).

My JRE_LASTEST does point to a valid directory under the Jaguar build.

Keith Roscarel
Access International

Andrew Hart wrote in message <38ADCE21.89FD6270@harcourt.com>...
>
>I hardly know where to begin on this one...
>
>We have a production server which has been giving us many problems over
>the past few weeks. We originally installed 3.0 on this server, which is
>locked away in a room and is being shared with another java based
>application for digital asset management called Teams from Artesia
>Technologies. ( http://www.artesiatech.com ). We have experienced a
>series of inexplicable problems with our jaguar installation on this
>machine: instability of the jaguar server, inability to view the
>srv.log file, etc. I'll fast forward to the latest evolution of the
>problem:
>
>We uninstalled Jaguar completely. First we did an uninstall, then we
>whacked all of the directories, and finally, we deleted all references
>we could find in the registry. Then, we reinstalled EAS 3.5, Advanced
>Deployment edition. First, we encountered problems in using JagManager
>on that machine. We launch the JaguarManager, we click on connect, it
>says in the status bar at the bottom of the window that we are
>connected, but upon trying to expand that branch of the tree, nothing
>happens. Remotely connecting with the new jaguar manager from another
>workstation, we were able to connect and everything seemed to work
>except that we couldn't view the srv.log file. It just comes up as
>empty with a file size of -1, although it is in fact NOT empty. On
>inspecting the log with a text editor we see error messages like:
>
>Feb 11 14:36:06 2000: FileViewer::Initialize - Failed to open log file:
>srv.log.
>Feb 11 14:36:06 2000: FileViewerImpl::_openLog() -
>intl_iocsfopen(srv.log, INTL_IO_READ) Failed.
>No such file or directory.
>
>We had originally encountered this problem under EAS 3.0. I posted a
>message regarding several days ago. At that time, the problem just
>magically went away and we were unable to determine why we had it in the
>first place and what fixed it. We suspected some sort of conflicts
>between the TEAMS software and Jaguar, since the last change to the
>server that we were able to identify was a change in some of the TEAMS
>services that were being launched. Now the problem is back, although,
>additionally, we are now unable to view ANY server information via
>JaguarManager run locally on the server itself.
>
>This morning, we were connected via JaguarManager from a remote machine
>and trying to set up some connection caches. During this process, the
>jaguar service (jagsrv.exe) crashed. Now, we are unable to get it up
>and running. I have an excerpt from the srv.log file:
>---------------------------------------------------------------------------
------------------------------------------------
>
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
>
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
>
>Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
>Feb 18 15:46:00 2000: Connection cache initialization failed
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
>
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
>
>Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
>Feb 18 15:46:00 2000: Connection cache initialization failed
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'
>
>Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
>'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'
>---------------------------------------------------------------------------
------------------------------------------------
>
>Now, we don't know exactly what sqllib18.dll is, but we know that
>ociwi2.dll is a typo and that it should be "ociw32.dll". We *think*
>that this misconfiguration might be causing the server to crash, but we
>don't know how to fix it without re-installing (for what would be about
>the 20th time). We tried running the JagRepair utility, but
>unfortunately, since we can't get JaguarManager to run we can't get in
>there to fix this.
>
>We have gone over our environment variables over and over and tried
>changng things to no avail. Currently, we have the following
>environment variables defined:
>
>---------------------------------------------------------------------------
------------------------------------------------
>
>CLASSPATH = .;F:\EAS35\Shared\Sun\Jdk118\lib\classes.zip;F:\EAS35\Jaguar
>CTS 3.5\html\classes;F:\EAS35\Jaguar CTS
>3.5\java\classes;f:\EAS35\Shared\PowerBuilder\classes.zip
>
>JAGUAR = F:\EAS35\Jaguar CTS 3.5
>
>JAGUAR_CLIENT_ROOT = f:\EAS35\Jaguar CTS 3.5\client
>
>JDK_LATEST = f:\EAS35\Shared\Sun\Jdk118
>
>JRE_LATEST = F:\EAS35\Jaguar CTS 3.5\jre
>
>PATH = F:\orant\bin;C:\WINNT\system32;C:\WINNT;C:\Program
>Files\Mts;f:\alchemy;C:\ntreskit;f:\JavaSoft\bin;g:\TeamsSrv\bin;F:\EAS35\J
aguar
>CTS 3.5\dll;F:\EAS35\Jaguar CTS
>3.5\client\dll;f:\EAS35\Shared\Sun\JDK118\bin;f:\EAS35\Shared\PowerBuilder
>
>User Variables....
>JS_JAGUAR=localhost:9000
>---------------------------------------------------------------------------
------------------------------------------------
>
>We're confused about the JRE_LATEST environment variable since the value
>(above) doesn't seem to be a valid directory. I am assuming that this
>is used only by the JaguarManager, not the Jaguar Server itself.
>
>SUMMARY:
>
>So, if anyone can give me some concise steps to troubleshoot this
>problem, I would be very grateful. As I've said, we've tried changing
>these environment variables, but nothing seems to work. We've copied
>over the settings from an installation that DOES work, with no success.
>We think there may be some conflicts with this other TEAMS java-based
>software, but we can't see it and are not sure what to look for since
>the CLASSPATH variable doesn't seem to contain anything pertinent to
>that package and the latest round of problems is occurring even when
>their software is not running. It doesn't help that the server is
>locked up and we don't have full access to the machine on a regular
>basis.
>
>Thanks.
>
>


Andrew Hart Posted on 2000-02-24 20:38:50.0Z
Newsgroups: sybase.public.easerver
Date: Thu, 24 Feb 2000 14:38:50 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Flakey EAS 3.5 Installation, HELP!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 46
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38B596DA.52BC1F29@harcourt.com>
References: <347_38ADCE21.89FD6270@harcourt.com> <347_TPr6Zpjf$GA.202@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:27894
Article PK: 159594

A followup: Our 3.5 installation appears to be stable now... we found a port
conflict with the other application we're sharing the server with on port 8081.
They had told us originally that no ports below 14000 or so were bing used. Not
knowing of a place to look for this info on the machine itself, we used a
network port scanner to look at the machine with Jaguar turned off and the other
application running to see what they were using. We knew we had a typo on the
database driver, but couldn't fix the server in repair mode because we can't get
jagmanager to run locally and couldn't seem to access the repair jaguar server
remotely. We reinstalled, fixed the error: We had oracle 8.x client software
installed on that server, so we had to put that in "oci.dll" for the driver
instead of "ociw32.dll". That eliminated the "sqllib18.dll" error. Now, our
only problem is that jagmanager doesn't run properly... we're sure it's some
problem with either the classpath, or some missing files. It's bombing out
trying to instantiate the class JaguarContainerVSO. We think we're slowly
stumbling toward a solution, but, as I said, access to the machine is
restricted.

As an aside to Sybase, it sure seems like the Jagmanager client installation
could be made to work more smoothly on Windows 95 machines.

Keith Roscarel wrote:

> We are trialing 3.5 and 3.0.1 on production servers.
>
> With regards to the crash when setting up the connection caches, we also
> came accross this in 3.5. The reason we had selected ODBC but had not
> supplied 'odb32.dll' as the driver. On the next restart, Jaguar crashed. A
> reinstall was our solution (and the supplying of the correct dll on the
> cache).
>
> My JRE_LASTEST does point to a valid directory under the Jaguar build.
>


Dave Wolf [Sybase] Posted on 2000-02-23 20:31:14.0Z
Newsgroups: sybase.public.easerver
From: "Dave Wolf [Sybase]" <dwolf@sybase.com>
Subject: Re: Flakey EAS 3.5 Installation, HELP!
Date: Wed, 23 Feb 2000 15:31:14 -0500
Lines: 163
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
NNTP-Posting-Host: dwolf-nt.sybase.com 157.133.41.127
Message-ID: <347_X8gYx1jf$GA.274@forums.sybase.com>
References: <347_38ADCE21.89FD6270@harcourt.com> <347_TPr6Zpjf$GA.202@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28022
Article PK: 159921

Please open support cases.

Dave Wolf
Internet Applications Division

"Keith Roscarel" <keithr@accint.com> wrote in message
news:TPr6Zpjf$GA.202@forums.sybase.com...
> We are trialing 3.5 and 3.0.1 on production servers.
>
> With regards to the crash when setting up the connection caches, we also
> came accross this in 3.5. The reason we had selected ODBC but had not
> supplied 'odb32.dll' as the driver. On the next restart, Jaguar crashed. A
> reinstall was our solution (and the supplying of the correct dll on the
> cache).
>
> My JRE_LASTEST does point to a valid directory under the Jaguar build.
>
> Keith Roscarel
> Access International
>
> Andrew Hart wrote in message <38ADCE21.89FD6270@harcourt.com>...
> >
> >I hardly know where to begin on this one...
> >
> >We have a production server which has been giving us many problems over
> >the past few weeks. We originally installed 3.0 on this server, which is
> >locked away in a room and is being shared with another java based
> >application for digital asset management called Teams from Artesia
> >Technologies. ( http://www.artesiatech.com ). We have experienced a
> >series of inexplicable problems with our jaguar installation on this
> >machine: instability of the jaguar server, inability to view the
> >srv.log file, etc. I'll fast forward to the latest evolution of the
> >problem:
> >
> >We uninstalled Jaguar completely. First we did an uninstall, then we
> >whacked all of the directories, and finally, we deleted all references
> >we could find in the registry. Then, we reinstalled EAS 3.5, Advanced
> >Deployment edition. First, we encountered problems in using JagManager
> >on that machine. We launch the JaguarManager, we click on connect, it
> >says in the status bar at the bottom of the window that we are
> >connected, but upon trying to expand that branch of the tree, nothing
> >happens. Remotely connecting with the new jaguar manager from another
> >workstation, we were able to connect and everything seemed to work
> >except that we couldn't view the srv.log file. It just comes up as
> >empty with a file size of -1, although it is in fact NOT empty. On
> >inspecting the log with a text editor we see error messages like:
> >
> >Feb 11 14:36:06 2000: FileViewer::Initialize - Failed to open log file:
> >srv.log.
> >Feb 11 14:36:06 2000: FileViewerImpl::_openLog() -
> >intl_iocsfopen(srv.log, INTL_IO_READ) Failed.
> >No such file or directory.
> >
> >We had originally encountered this problem under EAS 3.0. I posted a
> >message regarding several days ago. At that time, the problem just
> >magically went away and we were unable to determine why we had it in the
> >first place and what fixed it. We suspected some sort of conflicts
> >between the TEAMS software and Jaguar, since the last change to the
> >server that we were able to identify was a change in some of the TEAMS
> >services that were being launched. Now the problem is back, although,
> >additionally, we are now unable to view ANY server information via
> >JaguarManager run locally on the server itself.
> >
> >This morning, we were connected via JaguarManager from a remote machine
> >and trying to set up some connection caches. During this process, the
> >jaguar service (jagsrv.exe) crashed. Now, we are unable to get it up
> >and running. I have an excerpt from the srv.log file:
>
>---------------------------------------------------------------------------
> ------------------------------------------------
> >
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
> >
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
> >
> >Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
> >Feb 18 15:46:00 2000: Connection cache initialization failed
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
> >
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'sqllib18.dll'
> >
> >Feb 18 15:46:00 2000: DLL lookup failed for CM xagetconn
> >Feb 18 15:46:00 2000: Connection cache initialization failed
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'
> >
> >Feb 18 15:46:00 2000: AFLIB Message: 18011/11/0: DLL lookup for
> >'af_dll_lookup()' failed, OS Message: 'ociwi2.dll'
>
>---------------------------------------------------------------------------
> ------------------------------------------------
> >
> >Now, we don't know exactly what sqllib18.dll is, but we know that
> >ociwi2.dll is a typo and that it should be "ociw32.dll". We *think*
> >that this misconfiguration might be causing the server to crash, but we
> >don't know how to fix it without re-installing (for what would be about
> >the 20th time). We tried running the JagRepair utility, but
> >unfortunately, since we can't get JaguarManager to run we can't get in
> >there to fix this.
> >
> >We have gone over our environment variables over and over and tried
> >changng things to no avail. Currently, we have the following
> >environment variables defined:
> >
>
>---------------------------------------------------------------------------
> ------------------------------------------------
> >
> >CLASSPATH = .;F:\EAS35\Shared\Sun\Jdk118\lib\classes.zip;F:\EAS35\Jaguar
> >CTS 3.5\html\classes;F:\EAS35\Jaguar CTS
> >3.5\java\classes;f:\EAS35\Shared\PowerBuilder\classes.zip
> >
> >JAGUAR = F:\EAS35\Jaguar CTS 3.5
> >
> >JAGUAR_CLIENT_ROOT = f:\EAS35\Jaguar CTS 3.5\client
> >
> >JDK_LATEST = f:\EAS35\Shared\Sun\Jdk118
> >
> >JRE_LATEST = F:\EAS35\Jaguar CTS 3.5\jre
> >
> >PATH = F:\orant\bin;C:\WINNT\system32;C:\WINNT;C:\Program
>
>Files\Mts;f:\alchemy;C:\ntreskit;f:\JavaSoft\bin;g:\TeamsSrv\bin;F:\EAS35\J
> aguar
> >CTS 3.5\dll;F:\EAS35\Jaguar CTS
>
>3.5\client\dll;f:\EAS35\Shared\Sun\JDK118\bin;f:\EAS35\Shared\PowerBuilder
> >
> >User Variables....
> >JS_JAGUAR=localhost:9000
>
>---------------------------------------------------------------------------
> ------------------------------------------------
> >
> >We're confused about the JRE_LATEST environment variable since the value
> >(above) doesn't seem to be a valid directory. I am assuming that this
> >is used only by the JaguarManager, not the Jaguar Server itself.
> >
> >SUMMARY:
> >
> >So, if anyone can give me some concise steps to troubleshoot this
> >problem, I would be very grateful. As I've said, we've tried changing
> >these environment variables, but nothing seems to work. We've copied
> >over the settings from an installation that DOES work, with no success.
> >We think there may be some conflicts with this other TEAMS java-based
> >software, but we can't see it and are not sure what to look for since
> >the CLASSPATH variable doesn't seem to contain anything pertinent to
> >that package and the latest round of problems is occurring even when
> >their software is not running. It doesn't help that the server is
> >locked up and we don't have full access to the machine on a regular
> >basis.
> >
> >Thanks.
> >
> >
>
>