I am looking at the possibility of changing our Baan installation from Solaris / Oracle to NT/SQL, for a few reasons.

I'm quite clueless as to what this entails and would like any information / advice, both from an application /installation perspective as well as from a licensisng point of view.

Why not stick to this great DBMS and Unix? Why adding $ to MS?

Hi Bernard,

I have to agree with Omeluuk on this. Unless you have very good and solid reasons to move away from your current UNIX platforms - problems with SUN/hardware, lack of UNIX/DB admin skills etc - I would never consider making the jump to the NT/SQL server problem. Baan is and will always be a UNIX beast first.

NT? I have heard of customers with NT that reboot each night, for stability reasons. Most of them reboot once a week.

Unix? I also know of customers that reboot every month, just because they have heard rebooting is needed once in a while (they hear this from their windows admins, I guess). Sometimes I run into customers that have an uptime of over 300 days (AIX mainly...)

What do you want to choose for a mission critical application like Baan?

Everything's possible Bernard, but as Pat says..you better have good reasons to do this (and I for one am curious as to what those would be. I dare you to post them and watch us shoot them down one by one ;) ).

However, I am guilty of moving an AIX/Tbase system to NT/SQL back in '99. As a matter of fact, I think I had the doubtful honor of having the first MS-SQL configuration in Holland because we were delayed waiting for the unofficial release of v7.something.

I had my reasons at the time, and I still back those up.

And to pick-up on Luuk's lay-up....

I would definitely recommend rebooting NT _every_ night. The plus side is that most NT boxes will handle this without a problem and the whole process can be scripted and run unattended with a more than acceptable confidence level (at least in my experience).

As for Unix uptimes, we should battle that one out sometime on this board. Monthly or bi-monthly are my "official" recommendation by Baan.
From a hardware perspective you put your often expensive gear in jeopardy every time you hit the switch.
With proper maintenance you _should_ be able to keep a unix system up but.....BUT .... you would still have to bounce the Baan application (once a week as far as I am concerned).

As much as I have an experience with Baan/W2k/SQL2k configuraton, had rarely problems as up described. It is true that MS system need a lot of configuration to be made before installing Baan on it but if the configuration is correct, I think that Baan on MS system can be pretty much reliable configuration. If anyone of us can create a MS system and leave it, as Unix box I'm sure that it would work as good as Unix system. The biggest problem is that everyone thinks that it is easy to work with MS so everyone will try to do something [thinking that they know what they are doing] and the problems are born much easier than at Unix system. There are much more people thinking that they know what they are doing on Windows. And all of then are sure that they cannot work on Unix. So why should they bother to learn Unix when the MS is much easier. It isn't so!
If administrator on MS system can be good as the on the Unix system, application would have same performance and problems!
I'm not spitting on Unix, just saying that MS can be good too if the administration is good.

This first quote is from a pm (I also invited him to post his reasons in the thread itself):Bernard wrote on 4th September 2002 09:55:
In reply to your message....
At the time Baan was introduced to Sri lanka, it was only made available on Oracle / Solaris.

reasons for change;
We are on MS except for this
Cost of annual maintenance is prhibitively expensive.
Availability of skills and services
(hope he does not mind me posting this) Come and let's shoot them up :D
Originally posted by Francesco
Everything's possible Bernard, but as Pat says..you better have good reasons to do this (and I for one am curious as to what those would be. I dare you to post them and watch us shoot them down one by one ;) ).

However, I am guilty of moving an AIX/Tbase system to NT/SQL back in '99. As a matter of fact, I think I had the doubtful honor of having the first MS-SQL configuration in Holland because we were delayed waiting for the unofficial release of v7.something.

I had my reasons at the time, and I still back those up.I dare you to share them!And to pick-up on Luuk's lay-up....

I would definitely recommend rebooting NT _every_ night. The plus side is that most NT boxes will handle this without a problem and the whole process can be scripted and run unattended with a more than acceptable confidence level (at least in my experience).Oh, do not misunderstand me, I do agree on the mere fact that that is needed. My point is that it is definitly a bad thing that a mission critical server needs to have a downtime of some minutes every day! "We cannot work around the clock, for our server will not allow us to"... What a world we live in! There are good alternatives available. In this thread they are even in place!As for Unix uptimes, we should battle that one out sometime on this board. Monthly or bi-monthly are my "official" recommendation by Baan.
From a hardware perspective you put your often expensive gear in jeopardy every time you hit the switch.
With proper maintenance you _should_ be able to keep a unix system up but.....BUT .... you would still have to bounce the Baan application (once a week as far as I am concerned).True again.

Of cause there is this one argument: No-one knows how to handle Unix, but Everyone knows how to handle NT.
* Do you want this new server being tampered with by "Everyone". This will most probably become the most powerful system in the company with (initially) a lot of idle time... most tempting...
* Is the knowledge level of "Everyone" good enough to maintain a NT box as a Baan server. There are rather some specific issues that need to be addressed to. Issues that you won't see on plain MS platforms (stating that Baan is a more or less dualistic approach). The fact that user processess run on the server, taking resources is one thing. The combination of server specific tasks and client specific tasks. Login security upto database level. Screening the database from other native MS platform tools that can ruin the databases integrity
* There may be more to add...

As for costs... the new licence policy of MS is going to cost too. Buying expertise is expensive (I think it may be more in SriLanka), but there are lots of parties that can do this, sometimes even remote. If the hardware capacity is ok, then changing would only cost.

The other point is that old betamax discussion: having a lousy product but good marketing will win over the other way around... until MS tumbles down...

Just read the latest post, and good administration is of course important. Believe me, I do not say that NT is a bad choice. I do say that sticking with Sun/Oracle is a good choice, and because of the statement "Never change a winning horse" it is imho the best choice.

There is one more thing that I forsee with the MS platforms: update policies. Because of the speed of developing hardware, software, peripherals, newer faster and better alternatives for (already acceptable) components, it is hard to keep it all up. All of the changes are not needed for a stable Baan environment. But when support will fail because the lifecycle of a product is over (technically spoken, not economically), you will need to update. And updates are new nuisances... In that respect Unix seems to be more stable...

If MS admin is good he can take care that there is secured, very secured access to Baan/MS server.
Hardware is cheaper but licences are expensive. I do agree with that.
So I guess that there are advantages and "dissapointments" on all known platforms.
In both cases ... admin must know what he is doing on platform and in each case ... platform with its application can work without any problems and troubles.


Regards,

I dare you to share them!
The reasons I went to NT at the time can be summarized in Cost of Ownership, Scalability and Managability.

It was for a very small company (<25 consecutive users). Because of y2k issues we had to replace all existing soft- _and_ hardware anyway.

At the time, I also had to consider that Baan was about to go bankrupt and would go on the market. There was a lot of flirting going on between MS and Baan (more so then than now), so in that perspective I also thought MS would be a good bet.

Next time I'll take truth. lol


This first quote is from a pm (I also invited him to post his reasons in the thread itself):
quote:
--------------------------------------------------------------------------------
Bernard wrote on 4th September 2002 09:55:
In reply to your message....
At the time Baan was introduced to Sri lanka, it was only made available on Oracle / Solaris.

reasons for change;
We are on MS except for this
Cost of annual maintenance is prhibitively expensive.
Availability of skills and services

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

(hope he does not mind me posting this) Come and let's shoot them up :D

ooooo...kido, here goes.

1. We are on MS except for this
And your point is? Even if you switch to NT (or whatever it's called these days, you will have to maintain Baan on it's own _dedicated_ box.

2. Cost of annual maintenance is prhibitively expensive.
That depends on the number of users. You are probably right for environments with less than 50 users. It is important however to detemrmine the maintenance cost per user for both options and use that number for your comparison.
Don't forget to take the cost of migrating your system, divided by the life expectancy of the new system into consideration as well.

3. Availability of skills and services
That I can obviously not judge from here and I will have to take your word for it. I agree however with dvlahovic (and OmeLuuk) that 'the whole world' seems to think they can manage an NT system and that Unix has this aura of only being understood by bearded Guru's brewing up their mystic scripts in bomb-proof basements without ever seeing the light of day.
Both are obviously misconceptions (we do go out for lunch on Wednesdays).

Did I get 3 out of 3?

Originally posted by Francesco
I would definitely recommend rebooting NT _every_ night. The plus side is that most NT boxes will handle this without a problem and the whole process can be scripted and run unattended with a more than acceptable confidence level (at least in my experience).

As for Unix uptimes, we should battle that one out sometime on this board. Monthly or bi-monthly are my "official" recommendation by Baan.
From a hardware perspective you put your often expensive gear in jeopardy every time you hit the switch.
With proper maintenance you _should_ be able to keep a unix system up but.....BUT .... you would still have to bounce the Baan application (once a week as far as I am concerned).

How about an uptime of >365 days? As a policy we do not reboot servers on a regular basis. The only moment the application and database go down is for an offline backup. Rebooting a unix box to 'prevent' problems is in my eyes a myth. If your box is properly configured, patched, maintained and tuned, there is absolutely no reason for it to reboot any other than hardware interventions.

Originally posted by Francesco
3. Availability of skills and services
That I can obviously not judge from here and I will have to take your word for it. I agree however with dvlahovic (and OmeLuuk) that 'the whole world' seems to think they can manage an NT system and that Unix has this aura of only being understood by bearded Guru's brewing up their mystic scripts in bomb-proof basements without ever seeing the light of day.
Both are obviously misconceptions (we do go out for lunch on Wednesdays).

Did I get 3 out of 3?

Euh, not me. I do not claim NT expertise beyond desktop applications for sure. I do have a beard though :D

Originally posted by patvdv


How about an uptime of >365 days? As a policy we do not reboot servers on a regular basis. The only moment the application and database go down is for an offline backup. Rebooting a unix box to 'prevent' problems is in my eyes a myth. If your box is properly configured, patched, maintained and tuned, there is absolutely no reason for it to reboot any other than hardware interventions.

Agreed, although not all Unix OSs allow 'hot patching'.

Never the less, the recommendation I got from Baan (and didn't follow, to clear that part up) is a server reboot every 1 - 2 month(s).
Off course I never got an answer when I asked them what this supposably resolves other than "various things".

Database downtime should also not be a requirement in all cases.

The (only) reason I am bouncing Baan on a weekly basis is because of shared memory corruption (remember how much fun I had with that?).
As long as there is no way to rebuild or repair shm on the fly or to determine how and when shm corruption occurs, I am taking no chances and once a week that app goes down.

Originally posted by Francesco


Agreed, although not all Unix OSs allow 'hot patching'.

Never the less, the recommendation I got from Baan (and didn't follow, to clear that part up) is a server reboot every 1 - 2 month(s).
Off course I never got an answer when I asked them what this supposably resolves other than "various things".

Database downtime should also not be a requirement in all cases.

The (only) reason I am bouncing Baan on a weekly basis is because of shared memory corruption (remember how much fun I had with that?).
As long as there is no way to rebuild or repair shm on the fly or to determine how and when shm corruption occurs, I am taking no chances and once a week that app goes down.

Yeah of course I meant hardware interventions AND OS patching/upgrades. Got carried away there lol.

Still too often parties are recommending scheduled reboots to avoid the discovery of underlying problems. If the application works fine in week 1 and crawls to a halt in week 7, then it's always much easier to reboot the box every 3-4 weeks rather than trying to find the real cause of the problem.

Sorry to hear you are still struggling with the shared memory corruption Francesco :(

patvdv: How about an uptime of > 365 days?Which OS?Francesco: The (only) reason I am bouncing Baan on a weekly basis is because of shared memory corruption (remember how much fun I had with that?).
As long as there is no way to rebuild or repair shm on the fly or to determine how and when shm corruption occurs, I am taking no chances and once a week that app goes down.Isn't this past tense now? I heard things like "Shared Memory problems are over now" from Koen van den Dool... Then again, why not just reinitialize shared memory? Is that not enough?
patvdv: Sorry to hear you are still struggling with the shared memory corruption Francesco :(Did you try to have it running until week 7 or beyond lately? Of course your portingset needs to be up to date...

Originally posted by OmeLuuk
Which OS?

Always HP-UX!

The replies by all of you have been rich in content to help the decision to be made. Just to keep you informed, it is for an installation with < 25 users, and the nature of the business is such that some of the 'limitations' can be justified against cost.

Can you also help me by focusing on the details on the process of this changeover, (migrating data / licensing / compatibility of porting sets / migratinf customised components etc )because that too is vital for me.

The shared memory corruption I had caused a 'database disconnect' error with users. By bouncing Baan I attempt (thus far with success) to prevent this nasty issue.

I am not sure if initializing sm does the trick. I am not taking any chances.

As far as the latest porting set goes, I have heard that this one will resolve ALL our problems. :D

Unfortunately there are other issues that prevent me from doing a ps upgrade (I'm sure I ranted about that in another thread).

Aren't we drifting a wee bit off subject btw?

Shared Memory Server (shmserv.exe) starts looping, and consuming almost all CPU time.
Author K Van den Dool Creation Date: 08 Feb 2002 Alternate ID:
Solution No: 122213 Last Modified: 08 Feb 2002 Status: Published
Product: port7.1c.02 Sub Product: Session: shmserv.exe
Package: tt Version: B50 Release: c
Solution Type: QR:Program Error Standard S/WOn the knowledge base: search on Shared Memory, this is one example of Koen van den Dool's work...

Yeah we are drifting off. But your reply demonstrates so painfully what Pat stated:Still too often parties are recommending scheduled reboots to avoid the discovery of underlying problems. If the application works fine in week 1 and crawls to a halt in week 7, then it's always much easier to reboot the box every 3-4 weeks rather than trying to find the real cause of the problem.

Hi,

first I confess that I'm dedicated to unix.
Windows now has become a real alternative to unix because most of the advantages of unix where implemented in windows, eg. overcome of file system limitations, kernel-handling, tcp. The hardware is cheap and fast, but on the other hand the administration seems easier than it is.

As your home-work please try this simple tasks one on unix and once on Windows:

1) Change your ORACLE_HOME (one point):

old: ORACLE_HOME=c:\orant (/orant)
nw: ORALCE_HOME= f:\orant (/orant_new)

2) Change your BSE-Environment (one point):

old BSE= c:\baan\bse (/baan/bse)
new BSE=f:\baan\bse (/baan /bse2)


3) For the advanced (three extra points):

Install a second BSE-Environment and a second ORACLE-Environment on
your system. Create a company on each BAAN that is directed to the other
databases.

4) For the gurus (no extra points, but a bunch of honor):

Do task 3) with different BSE and Oracle-Versions!


;)

On a dual boot NT system?

After reading this long thread I couldn't resist to add my opinion:

- It's possible to have multiple BSE's/RDBMS instances on one NT machine, in fact I administer several that have that kind of configuration and basicly it's not more difficult than on Unix.
- I prefer Unix also more than NT. However I have learned the last two year that NT can be as stable a Unix as long as you have a capable admin and don't use it for several product on one system. The above mentioned systems do run several months without having them to reboot.
- Admin, using scripts is more easy to do on Unix than on NT, e.g. using a bshell wrapper script is a pain on NT, easy on Unix.


Rgrds,
Han

Originally posted by Bernard
Can you also help me by focusing on the details on the process of this changeover, (migrating data
I guess it is theoretically possible to lay a SQLnet or Baannet connection between your existing Oracle back-end and MSSQL. Once you created your tablespaces on the new DB it should then be possible to sync the two.
That would be a daring scenario however and if you have resources who can do that I wouldn't bother with the migration in the first place.
More realistic is to dump flat files from Oracle and import them (using exchange) into the new configuration.
Depending on wether or not you are also changing Baan versions this process would be fairly easy and managable.
licensing
You'll have to get all new licenses (don't shoot the messenger), but you might request a discount since you are trading in your existing Baan licenses.
compatibility of porting sets
Not sure what you mean. The porting set exists solely to make the standard Baan program communicate on different platforms, so I guess the answer is no, there is no compatibility there.
migratinf customised components etc
You should be able to recompile most customized components from their original sources (as long as you have those!!).
There are some commands that may have limited availability on NT or behave differently. I don't know if such a list exists, you might try the tools forum.

Originally posted by Francesco ... The porting set exists solely to make the standard Baan program communicate on different platforms, so I guess the answer is no, there is no compatibility there.That is true, but all that is available in the Sun release of portingset 6.1c.06.05 should basically also be there in the 6.1c.06.05 portingset for NT. Although it may be under a different name (explode6.1 becomes bic_explode.exe etc). Exceptions are there too of course: ba6.1 is not available for NT...You should be able to recompile most customized components from their original sources (as long as you have those!!).
There are some commands that may have limited availability on NT or behave differently. I don't know if such a list exists, you might try the tools forum. Basically the binary bshell objects should be compatible over different platforms. Actually all of the development in Baan is done on HP-UX, but also delivered to NT customers. The portingset assures this interoperability.

That is also one of the strong points of Baan... the application is fully portable... unless you do add hard coded systemcalls yourself. That you should test. But even the statement run.baan.prog will select the right binary name for the explode functionality on the different platforms...

Interesting thread at another discussion group -

Choosing an Infrastructure for Baan ERP (http://baan.ittoolbox.com/documents/document.asp?i=290)

I hatge to throw this out as I am a UNIX bigot as well. But, I have Win2000/NT accounts that have experienced run for three-four years with less than 2 days of unplanned downtime and rebooting only quarterly.

I believe the key to managing your NT/2000 box for maximum uptime is as follows:

1. Treat it like an enterprise server -- don't load the latest SP just because MS says so. (MDAC 3 for example)

2. Have a dedicated test environment for the testing of all patches before loading in production.

3. Buy from a reputable vendor and get the best disk you can buy. COnfigure it for performance not just all data on one RAID stripe beccause it is easy.

4. Invest in an enterprise level backup solution.

5. Do not put MS cluster services in plkace as this will make the environmet more difficult to manage and may introduce long-term instability as you have to manage the cluster patches on top of everything else (if you need HA, go with UNIX).

6. Keep it simple -- do not put anything else on your Baan server except Baan and the database.

7. Beware of the issues of authentication and make sure you PDC/BDC are set up and tested for failover to prevent authentication issues.

While there are more, I need to get on a ccon call.

I like HP-UX, AIX, etc. but let's not assume that NT is always bad -- I think that there are more bad NT admins... If you get some PC guy that treats his Baan NT server like a desktop, yes you will have problmes. Buty get a former mainframer/UNIX person that takes care of his box like it is the ERP server, and most of the problems seem to go away.

Just my opnion,

Jim

Originally posted by JamesV
5. Do not put MS cluster services in plkace as this will make the environmet more difficult to manage and may introduce long-term instability as you have to manage the cluster patches on top of everything else (if you need HA, go with UNIX).

From somebody with a lot of experience, this is an interesting statement. Proves that Baan on NT is not a scalable solution and not a viable option for a entreprise that must be able to count on reliability.