Conversion.

Mike

Mike

Moderator
Hi,

OS version:- HPUX
Progress version :- 9.1d with 32bit and 64 bit

We have two database with different version one is 9.1d 32bit and another is 9.1d 64bit .I have some doubts:-

Q1:- what are difference between 32bit and 64bit ? Is it coz of performance aspects?
Q2:- Can we convert 32 bit database to 64bit database .If possible how can we do? full backup and restore?
Q3:- Can we take dump of table from 32bit database and load in 64bit?


Thanks Mike
 
Databases don't have "bitness". The installed executables do.

There is no conversion of databases between 32 bits and 64 bits. There is nothing to do. You access the database with either 32 bit or 64 bit executables. If you are making shared memory connections everything needs to run from the same $DLC with whatever bitness that $DLC has. If you are making TCP/IP connections then you can start the server one way (usually 64 bit) and connect to it with the other.

The main difference, especially in something as old as v9, is that a 64 but executable can address a lot more memory. Which means that your -B buffer can be much larger. Which leads to better performance. Although... if you are on HPUX that may not matter. It has been 20+ years so my memory may be faulty but I seem to recall that vintage HPUX had some very restrictive limits on the size of shared memory. It _might_ be the case that 64 bit Progress gets around those. But I don't remember.

On UNIX systems you can check the bitness of the executables by using the "file" command with something from $DLC/bin as the argument. For instance:

Code: 
[tom@pt3dev]:~> file $DLC/bin/_mprosrv
/usr/dlc124/dlc/bin/_mprosrv: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=8f0878c746b3dd19cf84ff3ce1fd4de9ff57b481, not stripped

That is from my Linux dev box but the command works the same for HPUX. The output will mention "64-bit" if it is a 64 bit executable.
 
TomBascom said:
Databases don't have "bitness". The installed executables do.

There is no conversion of databases between 32 bits and 64 bits. There is nothing to do. You access the database with either 32 bit or 64 bit executables. If you are making shared memory connections everything needs to run from the same $DLC with whatever bitness that $DLC has. If you are making TCP/IP connections then you can start the server one way (usually 64 bit) and connect to it with the other.

The main difference, especially in something as old as v9, is that a 64 but executable can address a lot more memory. Which means that your -B buffer can be much larger. Which leads to better performance. Although... if you are on HPUX that may not matter. It has been 20+ years so my memory may be faulty but I seem to recall that vintage HPUX had some very restrictive limits on the size of shared memory. It _might_ be the case that 64 bit Progress gets around those. But I don't remember.

On UNIX systems you can check the bitness of the executables by using the "file" command with something from $DLC/bin as the argument. For instance:

Code: 
[tom@pt3dev]:~> file $DLC/bin/_mprosrv
/usr/dlc124/dlc/bin/_mprosrv: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=8f0878c746b3dd19cf84ff3ce1fd4de9ff57b481, not stripped

That is from my Linux dev box but the command works the same for HPUX. The output will mention "64-bit" if it is a 64 bit executable.
Click to expand...
Hi Tom,

Here , we have scenario that we are connecting with progress editor of 32 bit database via mpro but when we try to connect inside progress editor with 64 bit database its throwing version difference error.

So Is it possible to connect with 32 bit via progress editor and connect to 64 bit ?

Thanks Mike
 
Mike said:
So Is it possible to connect with 32 bit via progress editor and connect to 64 bit ?
Click to expand...
An ABL client can connect to an OpenEdge database in one of two ways: shared memory (also known as self-service) or TCP (also known as remote).

In order for a client to connect via shared memory it must satisfy the following constraints:
  • the client and database are on the same machine;
  • the client and database use executables from the same OpenEdge installation.
    • Technically, they don't have to be the same installation, but they must be the same release, architecture (32-bit or 64-bit), and shared-memory version. They could be different installs of the same release on different but compatible service packs. For example, 10.1B and 10.1B SP1 share the same shared memory version.
    • But in practice you can and should ignore the bullet point above, because when client and server are on the same machine, there is no reason for them not to use the same DLC installation.
If those constraints cannot be met by the client then it must connect via TCP/IP. This is done by specifying the client startup parameter "-S <n>", where <n> is the TCP port number of service name of a 4GL broker on the database. When a client connects to a database remotely, they can be different architectures, i.e. one is 32-bit and the other is 64-bit.

Example:
A database on machine A is started from a 64-bit Progress installation, with a 4GL broker on port 4444:
proserve mydb -ServerType 4GL -S 4444 <and other broker parameters...>

A client on machine B is started from a 32-bit Progress installation and connects to it remotely:
mpro mydb -H <machine A's IP address or hostname> -S 4444 <and other client parameters...>
 
There is no such thing as "32 bit database", there are databases that were started with 32 bit executables and there are databases that are started with 64 bit executables.

If your mpro startup parameters do NOT contain -S portNum then you are trying to connect via shared memory. In that case the bitness of the executables that you use to make that connection matters. See above:

> If you are making shared memory connections everything needs to run from the same $DLC with whatever bitness that $DLC has. If you are making TCP/IP connections then you can start the server one way (usually 64 bit) and connect to it with the other.

So your options:

1) Start the databases with a 64 bit proserve and connect, via shared memory & mpro that is also 64 bits. In other words $DLC is the same for both executables.

2) Start the databases with a 32 bit proserve and connect, via shared memory & mpro that is also 32 bits. In other words $DLC is the same for both executables.

3) Start the databases with a either a 32 bit or 64 bit proserve and connect, via mpro -S from any $DLC. Either a 32 bit or a 64 bit $DLC will work equally well for a database started with either bitness so long as you use -S.

Be wary of $PATH and $PROPATH containing multiple paths to multiple DLC locations in conflicting order. It is especially noxious if your scripts have something like:

PATH=$PATH:$DLC/bin
PROPATH=$PROPATH:$DLC

etc

If that gets executed by scripts that already have $DLC/bin in the PATH (or PROPATH) you will have multiple entries trying to define the location of Progress -- the first entry wins so adding something on to the end will not help you.
 
TomBascom said:
There is no such thing as "32 bit database", there are databases that were started with 32 bit executables and there are databases that are started with 64 bit executables.

If your mpro startup parameters do NOT contain -S portNum then you are trying to connect via shared memory. In that case the bitness of the executables that you use to make that connection matters. See above:

> If you are making shared memory connections everything needs to run from the same $DLC with whatever bitness that $DLC has. If you are making TCP/IP connections then you can start the server one way (usually 64 bit) and connect to it with the other.

So your options:

1) Start the databases with a 64 bit proserve and connect, via shared memory & mpro that is also 64 bits. In other words $DLC is the same for both executables.

2) Start the databases with a 32 bit proserve and connect, via shared memory & mpro that is also 32 bits. In other words $DLC is the same for both executables.

3) Start the databases with a either a 32 bit or 64 bit proserve and connect, via mpro -S from any $DLC. Either a 32 bit or a 64 bit $DLC will work equally well for a database started with either bitness so long as you use -S.

Be wary of $PATH and $PROPATH containing multiple paths to multiple DLC locations in conflicting order. It is especially noxious if your scripts have something like:

PATH=$PATH:$DLC/bin
PROPATH=$PROPATH:$DLC

etc

If that gets executed by scripts that already have $DLC/bin in the PATH (or PROPATH) you will have multiple entries trying to define the location of Progress -- the first entry wins so adding something on to the end will not help you.
Click to expand...
Hi Tom,
Thanks for reply,

Basically we have two databases account (dbname) and sale(dbname) :-

1: account (dbname) is starts with DLC path :- DLC=/progress9/dlc;export DLC and it starts successfully .
2:- sales (dbname is starts with DLC path :- DLC=/progress9_64/dlc;export DLC and it starts successfully.

As discussed ,

We can start database with any executables it may be 32 or 64 bit .But when I set DLC :- DLC=/progress9_64/dlc;export DLC for account (dbname)
and try to start it wont start. with error below. I tried to start with DLC 64 bit .If bit 32 or 64 doesn't matter why account database won't start if I set 64bit DLC? that is :- DLC=/progress9_64/dlc;export


10:43:17 BROKER 0: Multi-user session begin. (333)
10:43:17 BROKER 0: Begin Physical Redo Phase at 6272 . (5326)
10:43:19 BROKER 0: Physical Redo Phase Completed at blk 6370 off 6534 upd 0. (7161)
10:43:19 BROKER 0: Code page conversion table for GB2312 to ISO8859-1 was not found in convmap.cp. (6063)
10:43:19 BROKER 0: The code page of database /db/account is GB2312 and -cpinternal is ISO8859-1. (4677)
10:43:19 BROKER 0: The tables needed to do conversion for the database were not found in convmap.cp. (1564)
10:43:19 BROKER : Removed shared memory with segment_id: 1015831
10:43:19 BROKER : Multi-user session end. (334)
10:43:19 BROKER : ** This process terminated with exit code 2. (8619)
 
You have added some code page conversions to one of those DLCs but not to the other. So do whatever you did to the one that has them to the one that does not. You might also want to compare $DLC/startup.pf in the two DLCs and see if there are relevant differences.

This might be a good place to start reading about code page conversions: Progress Customer Community
 
You must log in or register to reply here.
Back
Top