Of course, early on (prior to V4R4 I believe) the reason for putting central objects on the deployment server / SQL Server - was because of the 32k blob limit on DB2/400. After a combination of JDE changes and changes in V4R5 (I think) - it became possible to store these long raw objects on DB2/400.
After looking after customers for several years on both sides, here is my analysis of this practice.
1. The AS/400 still "struggles" with long raw binary objects more than the other database types. Certainly it CAN support this data type, however, package builds and other BLOB based operations are substantially slower than any other platform. As an example, a full package build usually averages 10 to 12 hours on an AS/400, 3 to 4 hours on Oracle and can be completed in under 2 hours on SQL Server. Most of that time seems to be taken up in the PaktoTam and the GBRSPEC conversions. This has to be considered, from a performance perspective.
2. Putting the central objects and all other database files into a central database makes sense. Development costs money, and I view all of the central object repositorys as production, since there is cost involved (significant cost in many cases) with the data. It is better to place the central objects on the AS/400 and have it backed up as per all other data.
3. Licensing costs on a SQL Server result in increased costs. Costs on DASD versus Intel drives, on the other hand, can certainly offset this in many cases.
4. CNC Changes to the datasources to combine two different database types in your configuration means increased management, extra "layers" of unreliability and wasted manhours in maintenance.
In summary, moving the BLOBS to the AS/400 will slow down package builds compared to your current build times - but it will be more manageable and will equate to a better, cleaner CNC configuration.
As I've always stated in the past. It is POSSIBLE to use many database types and platform types in your Enterprise Network - but simplicity results in stability and manageability.
