Wanted to make sure one point was corrected, plus a few other comments.
You DO NOT have to IPL the 400 whenever you reboot NT. This would make the
400 as unstable as NT, which wouldn't be acceptable to anybody. You can
boot the NT machine either locally or remotely, (through NT commands or
OS/400 commands) without taking the 400 down, without taking any subsystems
down, etc. All you have to do is vary off the IXS device and vary it back
on.
One of the big reasons for moving the central objects to the same database
as the database server is to get rid of the extra cost/admin of a secondary
database, so that is definitely a good reason to do it. You also have
centralized backups and a lot easier administration. As others have
pointed out, you lose some performance, since you are now accessing a
remote database vs a local one, so you are going over the network vs local
disk. I haven't seen any direct comparisons, so I'm not sure WHAT the
actual difference is, but you'll need to consider your frequency and
current speed of package builds.
As pointed out below, the (more reliable, longer MTBF), 400 disks ARE more
expensive. With a deployment server, especially when you at least double
disk space for an upgrade, you have a lot of disk space sitting around not
really being used too often. Is it worth it to have that tied up in more
expensive 400 disks or cheaper standard SCSI PC disks? It migh depend on
the size of your implementation. If you already have a large 400 and an
extra 30-50GB on the 400 isn't a big deal, then it might make sense. If it
is a smaller environment, where disk cost is a higher percentage of the the
overall cost, it might not.
Regarding your question about speed. Generally the labs say that a given
MHz integrated card will perform better than the same speed standalone
server. If it is a very disk intensive workload, it will perform much
better, since the benefit comes from offloading the disk processing to the
400's disk subsystem, where on a normal PC type server, the intel processor
has to handle a lot of the disk workload as well as the regular processing.
In a package build, portions of which are very communications intensive,
(not necessarilty DISK intensive), and portions are processor intensive, it
is probably a wash and the net is you lose some performance because of the
communcications overhead. Also, some people recommend dual processor
systems for deployment servers, the integrated card is limited to a uni,w
hich works in a lot o environments The new 850MHz cards are a lot better
than the older, 333MHz cards, which still worked OK.
The nifty hot backup and easy switching of disk are definitely pluses for
the internal card, however, I'm not sure they are real important to a
deployment server. Depending on your environment, having a hot backup of
the deployment server redy to go, probably isn't a high priority. And
being able to have a NT4, W2k and other operating system image ready for
testing, probably doesn't apply to the deployment server either. They are
good for test boxes, or development environments, or having backup
webservers or TSE boxes, etc.
There is a new JDE whitepaper out on moving central objects, with steps on
how to do it that might be useful. I just saw it end of last week on the
Knowledge Garden. It's under the WWAT tips and techniques section,
entitled "Moving OneWorld® Central Objects to the AS/400® Platform"
Also, you can find some info on central objects and some on the Intergrated
card at:
http://www-1.ibm.com/servers/eserver/iseries/service/bms/jde-support.htm
I'm a proponent for of the integrated card, but of course, I'm one of the
IBMers that works with it, so take anything I say with a few grains of salt
Good Luck!
Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]
Sajaroff Sebastián <
[email protected]>@jdelist.com on 04/20/2001
04:34:06 PM
Please respond to
[email protected]
Sent by:
[email protected]
To: "'jeff_carey '" <
[email protected]>
cc: "'
[email protected]'" <
[email protected]>
Subject: RE: Central Objects on AS/400, IXS
Jeff :
a) You're partially right, if you move C.O. to the AS/400 (and you
have all your other tables there...) then you don't need Oracle anymore.
I've seen that packages builds deteriorates with C.O. on the
AS/400, remember that C.O. are read from a database. If that DBMS
resides on the Deployment server, it will be a local (and faster to
access to) resource. However, you will always need your Deployment.
It's impossible to have a OneWorld installation without a Deployment.
Deployment, among other things, creates client packages and you can't
compile them on an AS/400 box.
b) Another Horror story. Remember that NT needs quite frequent
reboots (for example, Service Packs, blue screens, software installations)
In case you need to boot your NT, you'll have also to IPL your AS/400!
Be aware that "cheap" NT will use expensive AS/400 disks, so ... if your
Deployment needs more disk you'll have to buy AS/400 disks not just
a 500$ SCSI Disk for Intel.
So, the morale of this story is :
a) A Deployment box is quite cheap now. Keep it separate from the AS/400.
b) According to my experience, fastest (and cheapest) packages build
occur on W2K/NT + MSSQL Deployment servers. Of course, I mean MSSQL
just for C.O., not for your data.