Currently we have 5.3.2 reporting servers on NT(Lotus Notes), Aix (Oracle) and AS/400(JDE,DB2). We also have Focus DB on any of the above. We will be upgrading to 7.6 soon. What are the advantages and disadvantages of consolidating on one WF Reporting Server (AIX or NT) with data connectors to the other servers.

PB,

APP MAP, in EDASPRF, will talk to any server. Should be fine...
Might want to check with IBI as 7.6 servers are configured differently now.
Others, hopefully, will chime in...

Some thoughts in response to your question:

1) You need FOCUS or an iWay (WF Rpt Srv) on the box where the FOCUS DBs are to be able to get to them.

2) Consolidating to one WF Rpt Srv license while using data apdapters to access Notes, Oracle and DB2 may save you some money in maintenance costs.

3) Less installs for you as the administrator would make it easier.

4) One install would allow you to create requests utlizing data from more than one data source. You might already be doing this right now anyway with multiple WF Rpt Srv.

5) If you use Report Caster, one install would make it easier for everyone to get at.

I hope this info helps and does not confuse the issue.

We use WebFOCUS on Windows to report from Oracle and MS/SQL on different machines. We license the Oracle and MS/SQL adapters. We also connect from WF on Windows to an iWay Srv on VM/CMS to access FOCUS DBs.

In some instances, you may not have a choice. For example, if you want to consolidate on AIX, how are you going to get to your Notes data on NT without a reporting server there - not an option because there isn't a Notes driver for AIX. Assuming that you have a database client for the desired platform that can access all other databases/platforms (DB2 client is pretty good at providing access to many platforms from one client) here are some pros and cons:
Pro:
-Metadata is all in one place and is easier to manage, both from operations and from disaster recovery points of view.
-Faster and more straightforward access to multiple data sources in single requests/apps. (No EDA synonyms, no -REMOTE BEING/END)
-Security may become simpler because you're using a single operating system for point of authentication

CONS:
-Security may become more difficult because you lose the ability to have different operating systems control who could access/run different things (can still be overcome with additional architecture)
-All reporting server agents are now competing for resource (temp disk space, memory) because they are running on the same box.
-"Putting all your eggs in one basket" if you don't have sufficient backup,redundancy, etc.

In my opinion, consolidation is best (which is what we have done in our environment) but the second con could be a killer if your resources are stretched (not a problem for us.)

One more note - after reading Mickey's post. You'll have to decide whether or not you can move all the FOCUS DBs to the same platform. As he mentions, you've got to have a server on the platforms where to FOCUS DBs are. If you can't move them, that takes away your consolidation options.

Be sure you research on the JDE requirements as well.

Thanks to all who replied. You're thoughts are pretty much the same as mine. Darin, we have been told that there is a JDBC connection for Notes on the AIX and we currently execute AIX applications from Notes parameter screens. The biggest thing we want to accomplish is to have the JDE data available with the Oracle data without having to convert one or the other to a Focus DB first.

We run 1 RCaster on the same server as all the other IBI products and access MS/SQL and Oracle RDB's on many other servers (worldwide) without any problems. No WF access to Notes. Our only FOCUS databases are intra-job and inter-job-refreshed-daily HOLD files kept in a separate directory under .../ibi/apps. Data Adapters on the WF server connect to all the other server's RDB's (even to some 'overseas' from the WF hosting server, and used subject to bandwith availablity).

We control who can get what by
(1) segregating Synonyms into separate libraries beneath /ibi/apps [eg: /apps/Oracle, /apps/SQLMSS/, /apps/HR, /apps/Finance, etc. 'baseapp' contains only 'public' synonyms].
(2) specifying access to synonyms for 'public' RDB's in the edasprof's APP PATH statement.
(3) controlling a user's access to RDB's by APP PREPENDPATH in his/her user-profile.
(4) all production RCaster jobs are defined by one WF Admin person and all are run with the same UserID ('rcaster') whose user-profile grants access to everything.

We use this method on 3 WF servers around the world, and find it quite easy to maintain.