We're planning to uprade our current installation (baan5c,solaris,oracle) to BaaN LN on a win2003 platform running MSSQL 2000/2005. But I have heard and experienced problems with shared memory on the windows platform some years ago and when patching I always had to restart shared memory on the win server.On the sun platform we do not has this problem.
Is this still an issue?

In 5c it's still the same, the architecture didn't change.

Regards,
Han

In 5c it's still the same, the architecture didn't change.

Regards,
Han


But how is it in BaaN LN?

Hello,
the shared memory -technology hasn't been changed - but you don't need to restart the server-you only choose if you want to load shared memory data or not by starting the shared memory service. I recommend that you will enable shared memory only at production - and if you patch some table /objects you can search the component in the console and delete it or restart the service and relogon.

Hello,
the shared memory -technology hasn't been changed - but you don't need to restart the server-you only choose if you want to load shared memory data or not by starting the shared memory service. I recommend that you will enable shared memory only at production - and if you patch some table /objects you can search the component in the console and delete it or restart the service and relogon.

Ok.Thanks Bruce!
Good to be a little prepared if we're going for the windows plattform this year :)

Sorry Ronny,

I wasn't clear enough in my post: you can use in 5c the same portingset as is used with LN and with that portingset the structure is not changed.

Regards,

the shared memory -technology hasn't been changed
Refer to the release notes of the latest Porting set 8.3a01

[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. With 8.3a only one segment was allocated, with 8.3a.01 additional segments will be allocated if needed.
Use previous shared memory manager behavior It’s also possible to fall back to the previous shared memory behavior, thus by using the binary shm_values6.2 and the parameter file $BSE/lib/shm_param Do so by adding the following line to $BSE/lib/defaults/all shm_compat_mode:1 On AIX this might give an issue with default start 30000000 value due to link option maxdata=20000000 -> start value might need to go to e0000000

Hello,
what you mentioned is only for Unix/Linux available..
-Bruce

In the release notes, there few sections specific to Unix/Linux and the rest are generic changes -

Porting set 8.3a or later
Shared memory management
With porting set 8.3a the memory segments used for shared memory are dynamically allocated during startup of the shared memory manager instead of based on the predefined segments defined in $BSE/lib/shm_param with the earlier porting sets. During the first start of shared memory the shared memory manager will log
in $BSE/lib/shm_config which size is default taken for the memory segment.example: # shm_segment_size:50331648
In this example the segment is 48Mb
Default size too small
It is possible that the default is too small for your environment. In that case you will see in the logfile $BSE/log/log.srdd_init6.2 the following message:
All memory blocks are used shmmanager6.2 -s
USED BYTES 592044 FREE BYTES 16185172 SHMID 13 NO ATTCH 6
Maximum allowed memory allocation
For all Unix/Linux systems:
The shared memory manager requires to be able (at default) to allocate 50331648 bytes of shared memory or any amount of bytes as specified in $BSE/lib/shm_config with the shm_segment_size:<size> resource. The
shared memory manager will fail to start if the kernel or operating system does not allow allocating requested amount of shared memory. The shared memory manager will then return with an error, indicating that allocation of
shared memory failed. The kernel settings, which dictate a minimum or maximum are system specific. For Linux systems: to be able to run the shared memory manager, the value in /proc/sys/kernel/shmmax need to have a value of at least 50331648.
For SUN systems: you need to add a line in /etc/system file like: set shmsys:shminfo_shmmax=<value>, where value should be at least 50331648. For other Unix systems: use the administrative tools for your OS to adjust the required kernel setting.

Chapter 8 Features
8.3a: Dynamic shared memory allocation
Upon startup the shared memory manager will create itself a $BSE/lib/shm_config file showing the defaults used and the shmmanager.6.2.log will show more detailed information about the memory
allocation and does not need predefined segments anymore. The file $BSE/lib/shm_param and binary $BSE/bin/shm_values have become obsolete.

I guess you still need to restart shm after table definitions etc are changed, and if you install a newer standard program (or have to remove manually).

It also does not give me hints that using shm on windows with several baan instances gives no problems anymore. Furthermore I have the experience that I need to restart shared memory sometimes before I can run bdbpost.

Guess that if you use one baan environment on your server and do a lot of exports and imports it should work.

Regards,
Han

You will have to do this until Microsoft moves off NTFS to a filesystem that has inodes that will record whether or not the block has changed.

Until then it would cause significant performance problems to have dynamic shared memory because you'd actually have to compare the whole file with the copy in shared memory. And do this every time the session/dd/etc is accessed.

Dave

I guess you still need to restart shm after table definitions etc are changed, and if you install a newer standard program (or have to remove manually).

It also does not give me hints that using shm on windows with several baan instances gives no problems anymore. Furthermore I have the experience that I need to restart shared memory sometimes before I can run bdbpost.

Guess that if you use one baan environment on your server and do a lot of exports and imports it should work.

Regards,
Han

But this can be done (restart shared memory) when users are logged on and when the server is in production?
Or else I have to schedule all updating/patching after worktime and that will be very bothersome:(

No but I guess you can't do that on unix either. Changed tables means reconfiguring it and during the reconfiguring you don't want to have users using these tables.

You can keep them running if you update e.g. your standard program. On unix you can keep running since on that platform baan detects that the object on disk has changed and reads that one.

On windows you can remove the object from shared memory with the NT manager (or restart shm after everyone gets out).

I install only small patches which only update program code of the application (not tools) during production and only after it has been verified that the new code works. All other patches/updates are done after normal working hours. On unix I would use the same procedure.


Regards,
Han

I find that sometimes shared memory just won't budge on Windows boxes no matter how many times you restart it.
When that happens only a full reboot of the server seems to refresh the contents.

It's a drag but oh well.

In most case there is no problem restarting shm with users logged on. For those already logged in, the data dictionary won't change during their session. If you are (almost) sure that they're not accessing your new objects (e.g. a new table rather than an updated one) then go for it.

Of course this is not best practice and if anyone asks... you didn't get it from me. :p

Of course this is not best practice and if anyone asks... you didn't get it from me. :p
From who:confused: :D

Thanks for your reply Francesco!