mig28mx
25th November 2008, 01:03
Sorry, I have posted in other forum!
Hello All,
I´m migrating my operation from HP-UX to Intel-RedHat ES.
My problem is the following:
When I try tu run shmvalues6.1 to create share memory, appear the following:
$ shmvalues6.1: cannot execute binary file
I'm suspect that shmvalues not come with the porting set, and it is a SO native program. It is correct?
Where I can find a Linux native shmvalues6.1?
My porting set is:
Product ver.: 6.1c.07.20
Port no : PA.3694
Any Ideas?
NPRao
25th November 2008, 01:19
Check the Porting Set Release Notes from the Baan Support Site
From the LN versions:
shmvalues6.2 removed
With 8.3a, shared memory allocation was changed. There was no longer a need for bin/shmvalues6.2 and lib/shm_param. The delivery of shmvalues6.2 has been dropped with this release.
[UNIX/Linux] Shared memory allocation changed
With porting set 8.3a.01, the allocation of a shared memory segment changed; the memory segments are allocated dynamically instead of based on the predefined addresses in $BSE/lib/shm_param with a default fixed size. Use previous shared memory manager behavior It is also possible to fall back to the previous shared memory behavior by using the parameter file $BSE/lib/shm_param.
The binary shm_values6.2 is removed, so you can no longer generate a new shm_param file. To fall back to the previous shared memory behavior you can change $BSE/lib/defaults/all by adding the following line:
shm_compat_mode:1
On AIX, this can give a problem with default start 30000000 value because of the link option maxdata=20000000 ->
Start value might need to go to e0000000.
Markus Schmitz
25th November 2008, 08:59
I assume you are on Tools 6.1 and not 6.2, so old BaanIV logic applies.
shmvalues is part of the Baan portingset, did you change the proting set to the red aht version?
What do you get, if you execute a "file shmvalues6.1" in $BSE/bin?
Regards
Markus
mig28mx
25th November 2008, 15:48
Hello,
This is the output that I get:
shmvalues6.1: ELF 32-bit LSB executable, Intel 80386, version1 (SYSV), for GNU/LINUX 2.2.5, dynamically linked (uses shared libs), not stripped
And yes, I have changed to a Linux porting set, to 6.1.c.07.20
Thank you.
Juergen
25th November 2008, 17:03
Hello,
please read the technical notes for porting set 6.1c.07.20.
Shmvalues6.1 removed
6.1c.07.17
With 6.1c.07.13 shared memory allocation was changed. There was no need
anymore for bin/shmvalues6.1 and lib/shm_param.
The delivery of shmvalues6.1 is dropped with this release.
Regards,
Juergen
mig28mx
25th November 2008, 17:07
Hello Jurgen,
Thanks for your time. I have already readed the technical notes for my porting set, and apply what it is recommended, but when I try to start the shared memory, apper a messge that says: shmparams file, empty.
Any other idea?
Thank you in advance.
Juergen
25th November 2008, 17:52
strange, but how did you start the shared memory.
manually ($BSE/bin/shmmanager6.1 -i) or with the script $BSE/etc/rc.start_shm ?
If you use the script, did you use the new version coming with the porting set ?
mig28mx
25th November 2008, 18:53
Hello Jurgen,
Actually, I can´t star the shared memory. I´m using the new file that comes with the porting set.
I´m reading a file where recomends that I can use an old version of shmparams, to create the shmvalues.
I'll give a try.
mig28mx
27th November 2008, 17:22
Hello all,
Just for inform you. The problem was solved using an old program from porting set 7.0. After create the shmvalues, the shared memory succesfully started.
By the way, after a long trip to get Baan running under RedHat ES and Oracle 10g (both on 64 bits) I´m thinking to upload a document where it describes the problems and solutions.
Regards.
Markus Schmitz
27th November 2008, 17:28
Actually I just read the Technical Notes to the 6.1c.07.20 Portingset and in there it clearly says, that the shmvalues binary and shm_param file is not needed anymore.
I think what happened is the following:
You changed the portingset, but you are using an old version for rc.start_shm in $BSE/etc. Here the script first checks, whether the shm_param files exists and if not, tries to create it by running shmvalues. This failed (because shmvalues) is not available, and the script aborts.
I think two thinks would have done the trick:
a) Create a dummy shm_param with the touch command.
b) Alternatively chaneg rc.start_shm to skip the check.
In a way you did (a), but the dummy looks very real!
Could you test this on your system?
Regards
Markus