Progress 9.1E and MS SQL Server 2005

J

jsingleton

New Member
Has anyone any exprience of running a Windows version of Progress 9.1E on the same server as MS SQL Server 2005? Are their any issues to consider?

Our current HR system runs under MS SQL and a proposed new Payroll system is written in Progress (9.1E we are told) and there is a requirement for them to work together.

Some of us are not convinced that this will not cause problems, despite reassurances from the suppliers.
 
Quite unlikely to cause problems, but why would you install a new payroll system based on an antique version of Progress?
 
Thanks, Tamahs.

The reason we are installing an old version of Progress is because the supplier of our HR system (written in MS SQL) could not cope with our requirements for a payroll system, so introdcued us to one of their business partners, who tell us their system is in Progress 9.1E. The decision as to which system to go for has been made in the very British way of looking at the Business needs rather than any technical issuess, so we Techies only get involved at the end, to clear up the pieces.

By the way, it is going to be replacing a payroll system written in some ancient runic language called Cobol, so we should be grateful for small mercys.

Thanks again.
 
Basing decisions on business functionality is laudable. Almost unheard of in some corners :rolleyes:

Thomas' point though was that the current release of Progress is OpenEdge 10.1C. 9.1E is 4+ years old and essentially unsupported. A newly purchased and installed package shouldn't be using 9.1E it should be using 10.1C.

As for co-existence...

There's nothing inherently wrong with the scheme from a "will these applications work together" POV so long as there are sufficient resources for both to be happy about it. You'll need enough RAM to go around and plenty of CPU and disk IO throughput (you'll need disk /space/ too but IO throughput is more often a problem). But without some information on the current and expected loads on the system its awfully hard to say if you're adequately configured.
 
Tom,

Thanks for that. It gives us some useful questions to ask of the suppliers when we next speak to them.

As for Progress 9.1E, the conversation would have gone something like this:

Me: What's it written in?

Senior management: Progress 9.1E

Me: You realise that version will not be supported by the time we get it installed.

Senior management: So? It works doesn't it?

As I said, there is rarely any reference to IT when thse descisions are made and money is handed over.

I will get the spec of the servr off our hardware guys.

John
 
Business issues *should* lead technical ones ... it is one of the reasons for success of many Progress partners. But, at some point in the process one should wonder why a company is delivering a product on ancient versions, especially when there are no technical barriers to being modern. I understand ... but don't approve of ... the practice in which a company buys version X of the partner's software running on version A of Progress, then customizes the package and can't easily upgrade to version Y, so the partner says that they can't migrate to a more modern of Progress and still be supported. This is a simple case of a stupid policy based on the vendor not wanting to test old versions of their software on new versions of Progress. But, that is not the case here. This is a new install, no modifications, and they are giving you a Progress version which is way behind the curve. There is almost certainly no excuse for this.
 
I agree with everything you say, but....

A bit more background. Having purchased, with an outlay of many thousands of Pounds (Dollars), an untried, untested and unseen (by us) system which included a payroll module which turned out to not meet our Company's requirements requirements, our HR Deaprtment were told by the Board of Directors, that they were not getting any more to spend, so were introduced by the original supplier to a sister company, whose product would do the job. This company thinks its product is, as we say in Britain, the bee's knees, albeit that it is in a retired version of Progress.

I, with a collleague, have been got the task of making the things work in co-existence. We do have many years of experience with a Unix vetsion of Progress.

For info the server spec, etc:

[FONT=&quot]The server is an HP DL360 G5 server with 2x 5160 processors ; 4Gb RAM ; and a 70Gb disk, partitioned for 24Gb system and 46Gb data.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]The server is running 64 bit Microsoft 2005 SQL server on 64 bit Windows 2003 operating system[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]The server is using Symantec Backup Exec SQL agent to secure SQL database each night.[/FONT]

Your comments are very much appreciated and are being fed through to the appropriate people.

John
 
1) If you have the source (and I'd certainly expect it if I were in your shoes) then there is no reason to stick with v9.

2) Your server has just 1 disk? That's not a high performance solution. If there is much of any workload on the system that is going to be your #1 performance problem.

3) Configuring, managing and tuning a Progress application isn't terribly hard but it is a niche and you may face some challenges. It's not like SQL server with "experts" on every street corner. This forum, PEG and PSDN are helpful but a training class or a week or so of a good consultants time will go a long ways towards setting the stage for success.
 
I just noticed the "many years with a UNIX version of Progress" comment. That should be a big help WRT to the server. If possible I'd implement the server on something like a Linux box... The windows box will work but, personally, I like Linux much better.
 
You must log in or register to reply here.
Back
Top