What OS do we choose?

We use RHEL 6 on our production DB server, RHEL 5 on our production web server (running the Webspeed Messenger), RHEL 5 on the development DB server and RHEL 5 on the development web server (again with Webspeed Messenger).

If i had to do it all again, i would drop RHEL in favour of Debian, easier to work with, easier to upgrade when necessary, etc...

If you know Unix, then picking up Linux is dead simple since they are pretty close in likeness to each other.

Windows vs. *Nix, it's a time old debate, personally with servers where you need high uptime, *Nix is a better choice (my opinion), the need to reboot it is extremely rare (our production DB server has been up for 67 days, but then, you can have a windows machine up for that long too (assuming you don't install windows updates).

We pay a support contract for RHEL, though we've never had to use it and it is a bit on the pricey side, one day, one day i'll be able to convince a change, though it would require a lot of work to do the switchover in the beginning.

The SCO to Linux migration will be easy and if you know SCO then you know 85% of Linux already.  I think this is a no-brainer decision.

Hi,

As has been already stated, it’s possible to have a stable, reliable server running on any of the OS’s listed.

There’s another factor you may want to consider. In current versions of Progress, the client has access to COM, the Windows API and the .Net framework. By client I’m including the AppServer and any Progress sessions you may choose to run on the server.

This allows you access to a world of features not easily available in Progress under Unix. Regular expressions, many more encryption types, any COM application like Excel or Word, easy HTTP or HTTPS communications and hundreds of other possibilities are directly available in your Progress code.

These are essentially extensions to the Progress language, many of which are difficult to do when running on Unix.

Tom Bergman

Tom.Bergman@WoltersKluwer.com

The only area I would anticipate having an issue with on RHEL is printing since your SCO box almost certainly uses printer scripts and RHEL uses cups.

@Thomas: Not even.  We set all the Linux printers to Generic:RAW as in these old-style applications it's usually the application that sends the ESC sequences to the printer.  The only thing I have had to do is add ESC&k2g (I think it's g) to change the CRLF behaviour on PCL printers.

Well, that depends on the application.  With mine, there were quite a large number of printers defined with different options for font, width, spacing, etc. and all of it was implemented with spooler scripts which supported option flags to produce the desired effects.   I.e., all the escape sequences and such were in the spooler script, making it very straight forward to provide equivalent output on different devices.  I thought it was a great design until we had to deal with cups and do it all over again.  Note that one of the things this approach provided was that it was very easy to print to disk and subsequently print to a printer from the disk file and get desired output.  And, we had scripts to do things like print to disk and print only the summary page at the end.  Admittedly, this implies no formatting like bold etc. with the document.  We did fancy printing too, but that was using the Kyocera Prescribe language.  Of course, this was a long time ago!

I agree with Paul, if you already have experience with SCO moving to Linux will not be a big obstacle. If you move to AIX or HP/UX it will not be transparent for the admins either. Especially with AIX :-)

That being said... If you set up and admin a Windows server appropriately you can also have decent levels of uptime.

How big is your database? How many users? Do you run a lot of reports? Expect the system to grow drastically in the near future?

I like Linux. Moving from SCO to LInux should be almost painless and
should have been done a long, long time ago. Your admins might have to
modernize some of their knowledge but nothing worse than moving from
Windows NT to Windows Server 2008. Don't feel like RH is the only
option -- it isn't.

Moving to AIX or HPUX would be more difficult. That Oracle-owned "UNIX"
probably shouldn't even be discussed.

As TMH mentions, printer setup is usually the most obvious challenge and
the biggest headache when making an OS change -- but that is true no
matter what choice you make.

It is certainly possible to run Progress on Windows and do so just as
successfully and with equal performance (on the same hardware) as for
Linux. It just isn't common. There are definitely exceptions in both
directions but, in my experience, Windows servers aren't /usually/ as
well configured and competently run as Linux servers. They *can* be
just as stable and reliable and perform just as well. But Windows
servers are often implemented by people without proper experience and
training and who are much more likely to take a "one size fits all"
approach that emphasizes cheapskate trade-offs that disproportionally
impact databases. Especially if virtualization is involved. Or
"corporate standards".

--
Tom Bascom
603 396 4886
tom@greenfieldtech.com

Why, Tom, and here I thought you thought the only way to tune a Windows box was by applying the Linux patch! :)

RE: What OS do we choose?

Reply by Thomas Mercer-Hursh

Why, Tom, and here I thought you thought the only way to tune a Windows box was by applying the Linux patch! :)

Stop receiving emails on this subject.

Flag this post as spam/abuse.

-- 
Tom Bascom
603 396 4886
tom@greenfieldtech.com

Wow.  Thanks everyone for your replies.  I was hoping that I got positive replies like yours, but one can never tell when you ask a Windows v Linux v Unix type of question.

We would have liked to move off SCO for a while, but other factors outside our control kind of held us back, as has the version of Progress that we are using.

In terms of knowledge and expertise within the IT department, we have 1 man who is good at Unix, and myself who is only average at Unix (I can get by with what I need to do on a daily/weekly basis).

Yes, I agree that most of these skills will be transferrable, although it is always the small percentage of differences that cause the problem.

We have talked about moving over to Linux for a while, but due to excessive work loads, it has never really gone any further.

With Windows, almost everyone in the IT department has some level of knowledge, and the Hardware team ALL have a very good knowledge, which is why we have thought it worth finding out more about the DB performance side.

We have a meeting on Wednesday this week to discuss it in detail with our IT Hardware Manager.

Some of you have said that performance is good and comparable, but even if we need a server that was 10% bigger in terms of hardware, if knowledge in the platform is higher and shared amongst many people, then this could be better in the long run.

Thanks again, and please continue to post replies if you have anything else to add.

The DBA types can certainly speak to this point better than I can, but my experience suggests that "familiarity" with an OS is different in character from Linux vs Windows.  Almost all of us have some familiarity with Windows because most of us use a Windows box for our work.  So, we know how to do all the routine tasks required to use the box.  But, that doesn't mean that we have the slightest clue how to tune the box to work as a database server.  Whereas, if we have even limited administrative experience with Linux, we actually have a lot of the skills needed to administer it for a dataserver and the additional skills are often fairly obvious and easily acquired.   With Windows, there is a lot more mystery.

The good doctor is correct: there is a big difference between being able to install Windows and start/stop services and knowing how to tune the OS appropriately. The good/bad news is that there are only a few tuning options on Windows.

Once you get the hardware set up and sized properly it isn't very hard to tune what you can. But in a lot of cases where you could just tweak a few Unix settings to get better performance you end up throwing hardware at it for Windows.

Either way you go... make sure you have a detailed performance testing plan that simulates real world conditions as much as possible before you make a hardware switch (of any kind).

Thanks guys for that useful insight.  I understand what you mean between setting it up and getting the best out of it...although I dare say, we haven't really done a lot to the current Unix server to improve performance.  All performance tuning has been done through Progress DB setup changes.

I might propose that we setup a Windows Server, and install our current 10.1C version, and then the current databases, and do some "real world" testing against it to compare the performance to our existing Unix server.  This will at least give us some guidance as to where we stand.  Comparing to Linux might not be possible in the short term, but if Windows turns out "poor", then I could then push for Linux.

Keep the advice comming, it is very useful, and thanks to all those who have already.