Progress 9.1B Error in Java Environment after moving server (proadsv and asbman)

P

PeterA

New Member
Hello

We moved our progress database to a new (virtual) Linux server. We have copied the full system with all files (operating system etc. included) to the new server. On the old machine, everything was working. We changed the server due to a potential disk problem and preventive (7 years old server, no more hardware maintenance available)

The adminserver proadsv does not start at all and shuts displaying a Java environment error:

Commands to start:
- for proadsv
# Proadsrv Startup
#!/bin/bash
#!/bin/bash
DLC=/export/apl/dlc; export DLC
PATH=$PATH:$DLC/bin: export PATH
PROPATH=$DLC; export PROPATH
PROMSGS=$DLC/promsgs; export PROMSGS
JDKHOME=$DLC/jdk; export JDKHOME
WORKDIR=; export WORKDIR
$DLC/bin/proadsv -port 9512 -start




PROGRESS Version 9.1B as of Sat Dec 9 16:17:33 EST 2000
vis:~# ldt_setup: modify_ldt: Invalid argument
SIGSEGV received at bf3ffd68 in /usr/local/lib/linux/native_threads/libjava.so. Processing terminated
Writing stack trace to javacorexxxx.txt ... (Example see attachment)

Commands for dbman

export DLC=/apl/dlc
export PATH=$PATH:$DLC/bin
export PATH=$PATH:/export/dat/sss
$DLC/bin/asbman -name sssns -start -port 9512
$DLC/bin/asbman -name sssap -start -port 9512


Is there any possibility to solve the problem? (Without upgrading to a newer progress version, this would be lead to change the software on about 400 Client machines)

With many thanks for any information.

PeterA
 

Attachments

I assume you left the old machine operational so you can compare its state to the VM.

Have you duplicated all of the directory structures between the two?

Have you compared the two machines to ensure that you have reproduced all environment variables?

Do non-java parts of Progress work? Can you start a database manually (via proserve)?

You could try to install Java, rather than use the version copied from the old machine. You could also try the same for Progress.

On a different tack, if installation effort is the only thing keeping you on 9.1B and preventing the installation of 10.2B or 11.1, then I don't know why you aren't planning for an upgrade, or at least a pilot project to test one. Failing that, you could at least move your back end to 9.1E, which shouldn't matter to your clients on 9.1B.
 
Dear Rob

Thank you for your quick reply

The Non-Java-Parts were working normally.

The cause was an incompatibility between the old Java machine and the newer Linux Kernel. We had to change the Linux kernel (and the file system) to bring the system to work.
Based on the information of our software supplier, any Upgrade would lead to change the clients. This is the reason we had this option only as the last, last way to resolve.

Now, the system is working.

Have a nice weekend!

PeterA
 
You must log in or register to reply here.
Back
Top